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The computers offered in this agreement, as well as the programs that Tl has created to use 
with them, are tools that can help people better manage the information used in their busi- 
ness; but tools— including Tl computers— cannot replace sound judgment nor make the 
manager’s business decisions. 

Consequently, Tl cannot warrant that its systems are suitable for any specific customer 
application. The manager must rely on judgment of what is best for his or her business. 
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2302663-9701 
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2270511-9701 
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DNOS 3270 Interactive 
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2302670-9701 


DNOS Online Diagnostics 
and System Log Analysis 
Tasks User’s Guide 
2270532-9701 

ROM Loader User’s Guide 
2270534-9701 

DNOS 3780/2780 

Emulator User’s Guide 
2270520-9701 
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Design Document 
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DNOS Software Manuals Summary 


Concepts and Facilities 

Presents an overview of DNOS with topics grouped by operating system functions. All new users (or 
evaluators) of DNOS should read this manual. 

DNOS Operations Guide 

Explains fundamental operations for a DNOS system. Includes detailed instructions on how to use each 
device supported by DNOS. 

System Command Interpreter (SCi) Reference Manual 

Describes how to use SCI in both interactive and batch jobs. Describes command procedures and gives 
a detailed presentation of all SCI commands in alphabetical order for easy reference. 

Text Editor Reference Manual 

Explains how to use the Text Editor on DNOS and describes each of the editing commands. 

Messages and Codes Reference Manual 

Lists the error messages, informative messages, and error codes reported by DNOS. 

DNOS Reference Handbook 

Provides a summary of commonly used information for quick reference. 

Master Index to Operating System Manuals 

Contains a composite index to topics in the DNOS operating system manuals. 

Programmer’s Guides and Reference Manuals for Languages 

Contain information about the languages supported by DNOS. Each programmer’s guide covers oper- 
ating system information relevant to the use of that language on DNOS. Each reference manual covers 
details of the language itself, including language syntax and programming considerations. 

Performance Package Documentation 

Describes the enhanced capabilities that the DNOS Performance Package provides on the Model 990/12 
Computer and Business System 800. 

Link Editor Reference Manual 

' Describes how to use the Link Editor on DNOS to combine separately generated object modules to 
form a single linked output. 

Supervisor Call (SVC) Reference Manual 

Presents detailed information about each DNOS supervisor call and DNOS services. 

DNOS System Generation Reference Manual 

Explains how to generate a DNOS system for your particular configuration and environment. 

User’s Guides for Productivity Tools 

Describe the features, functions, and use of each productivity tool supported by DNOS. 

User’s Guides for Communications Software 

Describe the features, functions, and use of the communications software available for execution 
under DNOS. 

Systems Programmer’s Guide 

Discusses the DNOS subsystems and how to modify the system for specific application environments. 

Online Diagnostics and System Log Analysis Tasks User’s Guide 

Explains how to execute the online diagnostic tasks and the system log analysis task and how to inter- 
pret the results. 

ROM Loader User’s Guide 

Explains how to load the operating system using the ROM loader and describes the error conditions. 

DNOS Design Documents 

Contain design information about the DNOS system, SCI, and the utilities. 

DNOS Security Manager’s Guide 

Describes the file access security features available with DNOS. 


iv 
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PREFACE 


This DNOS system design document contains the Information that Is 
needed to understand the operation of the system but Is not 
provided In other DNOS manuals. The document describes the flow 
of control of the operating system In general and of each of Its 
subsystems In particular. It also Includes data structure 
pictures, link streams, and directory Information for DNOS 
modules. Revisions made to this manual since DNOS 1,1 are marked 
with revision bars In the margins. 

This manual Is divided Into the following sections: 

Sect Ion 

1 How to Use the Design Document — Explains how to use 
this manual . 

2 Overview of DNOS — Discusses the general features of 
the DNOS system. 

3 Naming and Coding Conventions — Explains the 
conventions used In writing DNOS modules. 

4 DNOS Structure and Nucleus Functions — Discusses the 
overall structure of DNOS, common Interface routines, 
map file usage, major data structures, and queue 
server structures. 

5 IPL and System Loaders — Describes the process of 
Initial Program Load and the structures that support 
system loading. 

6 SVC Processing — Discusses the preprocessing done by 
the system, the several paths of control through 
supervisor call (SVC) processing, and how new SVC 
processors can be added to DNOS. 

7 Segment Management — Explains the structures, 

function, and use of segment management facilities of 
DNOS, 

8 Job Management — Discusses the job management flow 
of control and the data structures that support job 
management . 

9 Program Management — Describes the flow of control 
and the data structures used by DNOS In controlling 
bidding, loading, and synchronizing tasks. 
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10 I/O Subsystem Reviews the overall I/O processing 
structure and the details of handling of device I/O, 
I/O utility calls, Interprocess communication (IPG), 
file security, and name management. 

11 Disk Structures and File I/O ■**■*' Includes an overview 
of file management, a description of disk and in-^ 
memory file structures, and a detailed description of 
key Indexed file management. 

12 DNOS System Tasks Discusses the conventions used 
in writing DNOS system tasks and provides detailed 
descriptions of many system tasks provided with DNOS. 

13 System Generation Utility Provides an overview of 
the system generation utility and the data structures 
used. 

14 Logging and Accounting Describes the functions and 
the flow of control for the system log and job 
accounting functions. 

15 DNOS Performance Package Discusses the conventions 
used in system source code to enable the performance 
package and describes the routines executed in 
microcode . 

16 DNOS Development and Analysis Tools Describes 

several tools available to Texas Instruments internal 
users for development purposes only and several tools 
and command procedures available for general access. 

17 Analyzing a System Crash Describes the ANALZ 

utility functions and how to use them in analyzing a 
system crash file or in studying a running system. 

18 XOP Processing Describes the XOP processors in 
DNOS and how to add a new XOP processor. 

19 Special SVCs Describes SVCs used only by the 

operating system. 

20 Linking Information for DNOS Explains how to link 
DNOS and provides examples of link streams and link 
maps from building a DSR link, a link of a system 
task, and the link of the DNOS root. 

21 DNOS Source Disk Structure Describes the 

directories and files provided with a DNOS source 
ki t . 


Texas Instruments 


vi 
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22 Data Structure Pictures — Provides data structure 
pictures for DNOS data structures commonly needed to 
understand the system. 


A Keycap Cross-Reference - Discusses the generic keycap 
names that apply to all terminals that are used for 
keys on keyboards through out this manual. 


For further information related to the use of DNOS, refer to 
following document and those shown in the frontispiece. 

Title Part Number 

DNOS Source Installation Guide 2270515-9701 


the 
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SECTION 1 

HOW TO USE THE DESIGN DOCUMENT 

The description of DNOS design is divided into sections according 
to major operating system functions. The nucleus routines are 
described first, along with their data structures and the overall 
operating system structure. This section is followed by separate 
sections describing each of the major subsystems in DNOS. For an 
overview of all subsystems, skim through this document, reading 
carefully the overview portion of each subsystem section. For 
details on a particular subsystem or module within a subsystem, 
consult the detailed diagrams and discussion that follow the 
overview. 

Section 3 details naming conventions for the DNOS modules. When 
searching for details about a particular module, use the module 
name to determine which subsystem description is relevant. For 
details about particular data structures being used, consult the 
section on data structure pictures. 

The section on linking information provides example link control 
streams used to build pieces of the operating system. To build a 
device service routine (DSR) or a new system task, use these link 
examples as a guide in building the required link streams. Link 
streams are also shown for several other parts of the operating 
system to show how these pieces are structured. The DNOS link 
streams should be considered the primary source of information 
about the modules included to support a particular task or 
subsystem. The link streams are also the primary source for full 
pathnames for modules in DNOS. 

Most data structure pictures in this document are built directly 
from the templates copied into operating system source code. The 
structures are shown with hexadecimal byte counts, special 
comments, flags, and a diagram. 

Most of the special terms used to describe DNOS can be found in 
the glossary in the DNOS Concepts and Facilities manual. Other 
terms are defined in this document as they are needed. Acronyms 
for system structures and routine names are introduced at various 
points throughout the manual. If you read a section from the 
manual without reading all preceding sections, an acronym may be 
encountered without an explanation of its meaning. Table 1*1 
lists most of the acronyms used in the manual. Refer to this 
list in conjunction with the glossary for a complete description 
of the term. i 
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Table 1-^1 Acronyms Used in this Manual 


Ac ronym 


Meaning 


ACC 

ADR 

ADU 

BRB 

BRO 

BTA 

BTB 

CCB 

CDE 

CDR 

CDT 

DIA 

DIB 

DOR 

DPD 

DPR 

DSR 

FCB 

FDB 

FDR 

FID 

FIR 

FMT 

FSC 

lOU 

IPC 

IRB 

JCA 

JIT 

JMR 

JSB 

KCB 

KDB 

KDR 

KIB 

KIT 

KSB 

LDT 

LFD 

LPD 

LSE 

MRB 

NDB 

NDS 


Accounting record contents 

Alias descriptor record 

Allocatable disk unit 

Buffered request block 

Buffered request overhead 

Buffer table area 

B^tree block 

Channel control block 

Command definition entry 

Channel descriptor record 

Command definition table 

Diagnostic status 

Device information block 

Directory overhead record 

Disk PDT extension data 

DIOU Device Parameters 

Device Service Routine 

File control block 

File directory block 

File descriptor record 

File Identification 

File information record 

File management task area 

File structure common 

I/O utility task 

Interprocess Communication 

I/O request block 

Job communication area 

Job informa tion table 

Job manager request block 

Job status block 

KIF currency block 

KIF descriptor block 

Key descriptor record 

KIF information block 

KIF task area 

Keyboard status block 

Logical device table 

Log file definition 

Line printer PDT extension 

Load segment entry 

Master Read/Master Write buffer 

Name definition block 

Name definition segment 
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Table 1*^1 Acronyms Used in this Manual (Continued) 


Ac ronym 

4 ^ 


Meaning 


NRB 

OAD 

OAW 

OSE 

OVB 

OVT 

PBM 

PDT 

PFI 

PFZ 

PRM 

QHR 

RDB 

RIB 

RLT 

ROB 

ROM 

RPB 

RST 

SAT 

SCO 

SCI 

SDB 

SGB 

SLB 

SMT 

SOB 

SSB 

STA 

STE 

TDL 

TOL 

TPCS 

TSB 

UDR 

WCS 

WOM 

XTK 


Name manager request block 
Overlay area description 
Overlay area wait block 
Owned Segment Entry 
Overhead beet 
Overlay table entry 
Partial bit map 
Physical device table 
Program file directory index 
Program file record zero 
DIOU/IOU Parameters 
Queue header 

Request definition block 
Return information block 
Record lock table 
Resource ownership block 
Read-only memory 
Resource privilege block 
Reserve segment table 
Secondary allocation table ^ 

Track 0, sector 0 format 
System Command Interpreter 
Stage descriptor block 
Segment group block 
System log block formats 
Segment manager table 
Segment Owner block 
Segment status block 
System table area 
Swap table entry 
Time delay list entry 
Time-** ordered list 

TILINE peripheral control space 
Task status block 
User descriptor record 
Writable control store 
Waiting for memory queue 

Extension for a terminal with keyboard 
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SECTION 2 
OVERVIEW OF DNOS 


2.1 INTRODUCTION 

DNOS, a general purpose operating system for the 990 computer, is 
designed to meet a variety of computing needs. DNOS is a 
configurable operating system, allowing users to generate small 
systems with minimal software development capability; medium-^ 
range systems with a limited number of options; and large systems 
with a wide variety of system options. 

Among the special features available for DNOS are program and 
o ve r lay load ing , program swapping, key indexed files, dynamic job 
creation, output spooling, dynamic system configuration, 
interprocess communication (IPC), multiprogramming support, file 
access security, and a wide variety of utilities. 

A performance package is available for DNOS. It uses microcode 
implementations of a number of DNOS routines to enhance the 
processing speed of DNOS. 


2.2 GENERAL STRUCTURE 

DNOS is composed of memory^ res ident and disk^resident code. The 
memory^ res ident portion includes the following; 

* Device service routines 

* Interrupt processors 

* Extended operation (XOP) processors 

* System tables and device buffers 

* Many supervisor call (SVC) processors 

* Task scheduler 

* Nucleus support functions 

* Memo r y^ r e s i de n t tasks 
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These parts are linked when DNOS is generated, and they are 
loaded into memory during initial program load (IPL). This 
memory-*' res ident portion is referred to as the kernel of DNOS. 
The first portion of the kernel is referred to as the root; it 
forms the first segment of the mapping structure for kernel 
activities and for system tasks. 

Disk-President parts of DNOS include system tasks and overlays for 
some system tasks. These tasks include the I/O Utility, the Job 
Manager, and a number of miscellaneous SVC processors. These 
tasks are loaded into memory whenever their services are 
required • 

Most of the DNOS functions are performed by routines that serve 
queues of requests. A queue is a first-^in, first-^^out list of 
data to be processed. Each queue consists of a queue anchor, 
from which blocks of data are linked. Most queue anchors are 
located in the system root; those for file management are in the 
job communication area of the user job. The queues are singly 
linked, and the anchor points to the first data block, the first 
block points to the second, and so on. The anchor also points to 
the last block in the queue to enable efficient queue handling. 
The queue header format is displayed in the section of data 
structure pictures as the QHR, 


2.3 FLOW OF CONTROL OF DNOS 

While DNOS is running user jobs, the control paths vary. The 
diagram in Figure 2 *-! shows an overview of DNOS initialization, 
functioning, and termination. Detailed paths for the various 
subsystems are described in the following sections. 


Overview 
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Figure 2^1 Flow of Control in DNOS 
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2.4 DXIO COMPATIBILITY 

For a number of users, DNOS is an upgrade from the DXIO operating 
system. Most software that executes under DXIO executes without 
source change under DNOS. It needs only to be relinked with DNOS 
run-^tirae support. The notable exceptions are user-^wr i t ten DSRs, 
XOP processors, system tasks and utilities, and SVC processors. 
Several sections of this document describe the changes needed to 
make these pieces of software function under DNOS. 

Several system SVCs that were used with DXIO are not available 
for use in DNOS; in most cases, their functions are performed by 
a new SVC. 


Ove rvi ew 
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SECTION 3 


NAMING AND CODING CONVENTIONS 


3.1 NAMES OF ROUTINES 

DNOS modules are written in either assembly language or Pascal. 
In most cases, a module consists of one routine. When several 
small routines perform related functions, those routines appear 
in a single module. Each routine and module is named using the 
form aabbbb where aa is an abbreviation for the subsystem in 
which the routine fits and bbbb is a set of characters that 
describe the function of the routine. For example, JMHALT is the 
job management routine that processes the Halt Job SVC. 

Abbreviations for subsystems in the DNOS kernel and major 

utilities are shown in Table 3^1. 

Modules are organized into directories that correspond to DNOS 
subsystems. Table 3-^2 lists the major directories that comprise 
DNOS and indicates the section in which each directory is 
described. Other directories include modules for the various 
utilities of DNOS. The major directories labeled DNOS are 

detailed in this document; those labeled SCI, UTILITIES are 

detailed in the DNOS SCI and Utilities Design Document . 

The source library for DNOS has one or more of the following 

subdirectories for each of the directories: 


* PSOURCE for Pascal source 

* FSOURCE for Fortran source 

* SOURCE for Assembly language source 

* MSOURCE for / 12 microcode 

* MOBJECT for assembled microcode 

* MLIST for Microcode assembly listing 

* TSOURCE for Link Editor modules needing to be 
transliterated from POPs code to assembly language 

* UTILITY for the transliteration utilities for linker 
code 
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Table 3^1 DNOS Subsystem Abbreviations 


Abbreviation 


Subsystem or Utility 


D$ 

DM 

DS 

DU 

E$ 

FM 

10 

IP 

lU 

JM 

KM 

LG 

MB 

NF 

NM 

01 

PL 

PM 

RP 

SE 

SL 

SM 

SO 

SP 

TP 

UT 

aaa 


Debugger 

Disk management 

Device service routines (DSRs) 

Device I/O Utility 
Text Editor 
File management 
I/O routines 

Interprocess communication (IPC) 

I/O utilities 
Job management 

Key indexed file (KIF) management 
System log and accounting log 
Mailbox 

Nucleus functions 
Name management 
Operator Interface 

Pas cal-^to*assembly^ language interface 

Program and memory management 

Request processing ^ SVC support 

Security 

System loaders 

Segment management 

System overlay management 

Output spooler 

Teleprinter device utilities 

Subroutines common to several utilities 

SCI utilities * aa or aaa is the SCI command 


Coding Conventions 
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Table 3^2 

Major Directories of DNOS 

Directory 

Location 

of Documentation 


^ -4^ 



ANALZ 

DNOS 

^ Section 

17 

BATCH 

DNOS 

^ Section 

21 

DEBUG 

DNOS 

- Section 

16 

DEBUGGER 

SCI, 

UTILITIES 


DEVDSR 

DNOS 

^ Section 

10 

DIOU 

DNOS 

- Section 

10 

DISKMGR 

DNOS 

Section 

12 

EDITOR 

SCI, 

UTILITIES 


FILEMGR 

DNOS 

- Section 

11 

lOMGR 

DNOS 

Section 

10 

lOU 

DNOS 

- Section 

10 

IPG 

DNOS 

^ Section 

10 

JOBMGR 

DNOS 

Section 

8 

KIFMGR 

DNOS 

- Section 

11 

LINK 

DNOS 

- Section 

20 

LOADERS 

DNOS 

Section 

5 

LOG 

DNOS 

■**’ Section 

14 

LOGON 

DNOS 

- Section 

12 

MACROS 

DNOS 

^ Section 

3 

MAILBOX 

SCI, 

UTILITIES 


MESSAGES 

SCI, 

UTILITIES 


NAMMGR 

DNOS 

- Section 

10 

NUCLEUS 

DNOS 

^ Section 

4 

OPERATOR 

SCI, 

UTILITIES 


PASASM 

DNOS 

Section 

3 

PERFORM 

DNOS 

- Section 

15 

PROGMGR 

DNOS 

^ Section 

9 

REQPROC 

DNOS 

^ Section 

6 

RESTART 

DNOS 

■*' Section 

12 

S$ 

SCI, 

UTILITIES 


SCI990 

SCI , 

UTILITIES 


SECURITY 

DNOS 

- Section 

10 

SEGMGR 

DNOS 

Section 

7 

SPOOLER 

SCI , 

UTILITIES 


SYSJEN 

DNOS 

^ Section 

13 

SYSOVLY 

DNOS 

- Section 

12 

TEMPLATE 

DNOS 

Section 

3,22 

TIGRESS 

DNOS 

^ Section 

16 

TPCALANS 

SCI, 

UTILITIES 


UTCOMN 

SCI , 

UTILITIES 
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3.2 GLOBAL DATA AND STRUCTURE TEMPLATES 

Names of system tables and data structures are generally three 
characters long, with the characters chosen to reflect the 
structure name. Fields within the structure have six^character 
names (whether part of Pascal records or assembly language code); 
the first three characters are the same as the structure label. 
Flag fields within the structure are detailed using equates, with 
each flag bit (or set of bits) identified by aaFbbb where aa 
represents the first two characters of the structure name, F 
indicates a flag, and bbb describes the flag. For example, the 
task status block is the TSB. TSBPRI is the name a field within 
the TSB that carries the task priority, TSFSYS names a flag in 
the TSB that indicates whether a task is a system task. 

Global constants and error equates are named using these formats: 

WDaaaa DATA >aaaa 

ERRaa BYTE >aa 

BYTEaa EQU ERRaa 

where a is a hexadecimal digit and > is used to represent a 
hexadecimal value. 

The TEMPLATE directory contains the global constants and 
variables used by DNOS source code. In the following list of 
subdirectories of the TEMPLATE directory, DSC is a synonym for 
the entire DNOS source directory. All of these directories, 
except the PREAMBLE directory, also appear in the linkable parts 
directory .S$OSLINK on an installed DNOS system. 

DSC.TEMPLATE. ATABLE 
DSC. TEMP LATE. COMMON 
DSC. TEMPLATE .DECLARE 
DSC.TEMPLATE . PREAMBLE 
D SC. TEMPLATE. PTABLE 


The D SC . TEMPLATE . ATABLE directory contains templates for DNOS 
data structures that are used by assembly language routines. 
Files in this directory are copied into an assembly language 
module to reference fields within the data structures. A module 
accesses a particular field in a structure by using a template 
offset with a pointer. The pointer can be passed to the module 
or retrieved from some other DNOS structure. This directory also 
includes a template of system crash codes (NFCRSH) and a template 
of task states (NFSTAT). Files from this directory are shown in 
detail in the section on data structure pictures. They are built 
using the picture macros described in the section on DNOS 
Development and Analysis Tools. 


Coding Conventions 


3-4 


2270512-9701 



DNOS System Design Document 


The DSC . TEMPLATE . COMMON directory contains the common data used 
by assembly language routines. It consists of files of CSEG 
blocks, including the following major files: 

* DSC. TEMPLATE. COMMON. NFDATA Global data values for the 

current state of the system 

* DSC . TEMPLATE . COMMON . NFERnO Byte constants (>n0 through 

>nF) and equates for system error codes (16 such 
templates ) 

* DSC . TEMPLATE . COMMON . NFPTR * System pointers to global 
lists and structures 

* DSC. TEMPLATE. COMMON. NFWORD - Word constants 


Any assembly language module that makes use of a byte constant or 
a word constant copies the appropriate common template and uses 
the constant in that module. Similarly, NFPTR and NFDATA are 
copied into a module to allow access to a system pointer or 
global data item. Use of the templates provides documentation of 
all uses of a particular error code, constant, or system 
variable . 

NFPTR Includes pointers to system queues, pointers to beginnings 
of structure lists, addresses of segment management tables, 
pointers to device information, and several miscellaneous 
pointers. Full details on NFPTR appear in the section on data 
structure pictures. 

NFDATA includes anchors for several system data structures, 
counts for jobs and tasks in the system, parameters for system 
time units, sizes of the system and system files, scheduling 
data, a word of flags which define system options chosen at 
system generation, and several other items. Details of NFDATA 
are shown in the section on data structure pictures. 

The D SC . TEMPLATE . DECLARE directory is used by Pascal routines. 
It consists of files of procedure declarations, which are copied 
into Pascal modules. Each subsystem or utility written in Pascal 
has a file of declarations for its own set of modules. Also, 
declarations are included for run-^time routines and for interface 
routines from Pascal code to assembly language modules. 

The DSC . TEMPLATE . PREAMBLE directory has the templates for 
documentation preambles to assembly language and Pascal source 
modules . 
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The DSC . TEMPLATE . PTABLE directory has data structure templates 
and common segment templates for use by Pascal code. The 
directory includes files corresponding to each of those in the 
DSC. TEMPLATE. ATABLE and D SC . TEMPLATE . COMMON directories. Also, 
it has a number of files that have no counterparts in the other 
directories but are needed by Pascal routines. 


3.3 ASSEMBLY LANGUAGE CODING CONVENTIONS 

Each assembly language module begins with a preamble that 
describes that module. Fields in the preamble template that are 
not used for a particular module are omitted in that module. In 
the assembler template, the following are required sections: 

copyright statement errors 

routine name revision 

abstract environment 

entry IDT name 

exit PSEG, code, and END 

When more than one routine is included in a module, each routine 

is preceded by a description that includes abstract, entry, exit, 
and error information. 

The abstract gives a brief English description of the general 
purpose of the module, while the algorithm section describes how 
the routine works. The environment section points out what table 
areas are used by the module. Revision information is provided 
in the format shown below. Other entries are self-*'explanatory . 

* REVISION: <creation date mm/dd/yy - ORIGINAL 

* <reviston ID> ^ <date> <purpose> ^ <0S release no> 

* repeated, with latest revision last 


where : 


<revision ID> is a pair of decimal digits, beginning 
with 01. 

<date> is the form mm/dd/yy, where each field 

is decimal. 

<purpose> is description of the change. Including 

the number of any STR on design request 
being satisfied by this revision. 

<0S release no> is the release for which this revision 
was prepared. 


3 -^ 6 
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To keep track of which lines of code were added for what 
revisions, each added line is flagged. In columns 58 through 60 
of the line added to an assembly language module, the characters 
Rmn are inserted, where <mn> is the revision ID specified for 
this revision in the preamble. 

Templates copied into assembly language programs with the COPY 
statement are by default UNListed. (Data templates and other 
structures are surrounded by UNL and LIST. To see the copied 
items, the program may be assembled with the FUNLST (F) option of 
the assembler enabled.) 

For the most part, assembly language code uses tab settings of 1, 
8, 13, 31, and a right margin of 60 to make the assembly listing 
as legible as possible. Comments are included in the preamble 
and in atoms within each routine. An atom is several lines of 
comments, set off from the code it describes. 

Labels used within an assembly language routine are composed of 
three characters followed by three digits (for example, OPNlOO 
for a label in a routine performing open processing). The 
characters are chosen from the routine name unless another set of 
characters is clearly more useful. The numeric portion ends in 
zero to allow room for inserted labels, and labels appear in 
ascending numeric order from beginning to end of a module. 

The format of the assembly language preamble is as follows : 
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* 

* 

* 

* 

■k 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

■k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 


k 

k 

k 

k 

k 


k 

k 


TITL '<MODULE ID - SHORT DESCRIPTION> ' 

(C) COPYRIGHT, TEXAS INSTRUMENTS INCORPORATED, 1983. 

ALL RIGHTS RESERVED. PROPERTY OF TEXAS INSTRUMENTS 
INCORPORATED. RESTRICTED RIGHTS - USE, DUPLICATION 
OR DISCLOSURE IS SUBJECT TO RESTRICTIONS SET FORTH 
IN TI'S PROGRAM LICENSE AGREEMENT AND ASSOCIATED 
DOCUMENTATION. 

ROUTINE NAME; <NAME OF R0UTINE(S)> 

ABSTRACT: <DESCRIBE THE GENERAL PURPOSE OF THIS R0UTINE> 

ENTRY; <INSTRUCTION/STATEMENT/ INTERRUPT USED TO ENTER> 

(<RN>) = <DESCRIPTION> 

EXIT; (<RN>) = <VALUE> IF <CONDITION> 

ERRORS; <ACTION OR CODE> IF <CONDITION> 

STACK REQUIREMENTS; <N> WORDS 

ALGORITHM: <DESCRIPTION OF ALGORITHM IF NECESSARY> 

REVISION; <CREATION DATE IN MM/DD/YY> - ORIGINAL 
<REVISION DATE; LATEST LAST> - <NATURE> 

ENVIRONMENT: 990/10 ASSEMBLER 

CALLABLE FROM <assembler , Pascal> 

TABLE SEGMENTS MAPPED IN WHEN ENTERED; 

<LIST> 

TABLE SEGMENTS MAPPED IN DURING ROUTINE; 
<LIST> 

NOTES; <SPECIAL CONDITIONS/ ASSUMPT IONS OR OTHER 

SPECIAL INFORMATION> 


SUBROUTINE REFS: 

REF <NAME> <DESCRIPT ION> 

CONDITIONAL ASSEMBLY; 

<VARIABLE> <DESCRIPTION> 

MACROS TO BE USED; 

LIBIN DSC .MACROS .TEMPLATE 

LIBIN DSC.<MACRO LIBRARY PATHNAME> 


* EQUATES; 

<NAME> EQU <VALUE> <DESCRIPT ION> 

* <INSERT COPIES OF EQUATE FILES IF ANY> 

* 

* GLOBAL DATA (TO SHARE AND ACCESS DATA IN COMMON AREAS) 
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* 

* <INSERT COPIES OF ANY RELEVANT CSEG FILES> 

PAGE 

* 

IDT XMODULE NAME>' 

DEF <MODULE NAME> 

PSEG 

<ROUTINE CODE> 

END 


Several macro libraries are available in the MACROS directory for 
use by assembly language routines. In each case, the SOURCE file 
shows the macro definitions and documents their use. To find out 
how a particular macro functions, read the comments in the source 
file for the macro. 

The DSC. MACROS. TEMPLATE library must be included with a LIBIN 
statement in most modules that use data structure templates. 
Many of the templates in the DSC . TEMPLATE . ATABLE directory are 
defined using macros that allow processing in assembly language 
and Pascal structures. It includes macros for ADDR, BITS, CHAR, 
FLAG, FLAGS, LONG, PTR, RECORD, WORD, INT, PCKREC, ENDREC, REC, 
ARRAY, POSINT, and VARNT . 

In the rare instance that a CSEG must be used as a DSEG, the set 
of macros in DSC . MACROS . DORGCSEG should be used. This set 
includes macros for CSEG, CEND, and DZERO directives. These 
macros are often used by modules that issue the Retrieve System 
Data SVC (>3F) to access a part of a system common area. The SVC 
expects the user to specify an offset into the common area (as a 
DSEG would allow) rather than an absolute CSEG address. 

The D SC . MACROS . FUNC library includes macros to inhibit and enable 
scheduling, to initialize a block of data, to test conditions 
during assembly of code, and to provide common subroutine access. 
This set includes macros for ASSUME, DATAM, ENAB, INHB, SCALL, 
SPOP, SPUSH, GTA, GTAO, RTA, PRCK, SGCK, SRTN , and TRTN. These 
macros must be used for the purposes described in Table 3-3. See 
the FILE DSC . MACROS . FUNC . SOURCE for the descriptions of the macro 
details. All accesses to the routines indicated in Table 3-3 
must be made using the macros, since the macros provide access to 
performance microcode^ 
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Table 3*3 Macros from DSC . MACROS . FUNC 


MACRO NAME 


PURPOSE 


ASSUME 

Test an 

assembly condition, (gener 


a 

template field) 


DATAM 

Generate data fields 


DCLOSE 

Door Close 


DOPEN 

Door Open 


ENAB 

Access 

NFENAB to enable 

scheduling 

INHB 

Inhibit 

scheduling 


SCALL 

Call another routine 


SPOP 

Access 

NFPOP 


SPUSH 

Access 

NFPSH 


GTA 

Access 

NFGTA 


GTAO 

Access 

NFGTAO 


PRCK 

Access 

RPPRCK 


SGCK 

Access 

RPSGCK 


RTA 

Access 

NFRTA 


SRTN 

Access 

NFSRTN 


TRTN 

Access 

NFTRTN 



Macros in DSC .MACROS . UTILITY are used by a number of DNOS and SCI 
utility programs to perform commonly needed operations. It 
includes macros to terminate a program under abnormal error 
conditions and a variety of special field initialization macros. 

A set of macros is available to build assembly language routines 
to be called by Pascal routines. These macros yield code 
compatible with Pascal subroutine conventions. The macros are in 
the library named DSC .MACROS . RIFLE .MACROS . 


3.4 PASCAL CODING CONVENTIONS 

Several subsystems are written in a subset of TI Pascal. These 
include job management, system generation (sysgen), system log 
processing, accounting log processing, and many SCI utilities. 

Statements are written one per line, and segments of programs are 
visibly separated to facilitate readability. As with assembly 
language programs, Pascal programs are documented in the preamble 
and throughout the code. To allow printing of source code on Any 
available printer, only uppercase characters are used. 

In the Pascal template, the following fields are required: 
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compiler options revision 

copyright statement environment 

program statement procedure (function) and code 

abs tract 

The revision information must be of the following format: 

" REVISION: <creation date mm/dd/yy ORIGINAL> 

" <revision ID> <date> <purpose> ■*' <0S release no> 

" repeated, with latest revision last 

To keep track of which lines of code were added for what 
revisions, each added line is flagged. For Pascal code, the 
characters Rmn are inserted with a comment indicator after column 
60 . 


The preamble template for a Pascal module is of 
form: 


the 


following 


(*&FILL-, ADJT-,SLIM(72)*) 

fi 

" (C) COPYRIGHT, TEXAS INSTRUMENTS INCORPORATED, 1983. 

" ALL RIGHTS RESERVED. PROPERTY OF TEXAS INSTRUMENTS 

" INCORPORATED. RESTRICTED RIGHTS ^ USE, DUPLICATION 

" OR DISCLOSURE IS SUBJECT TO RESTRICTIONS SET FORTH IN 

" TI'S PROGRAM LICENSE AGREEMENT AND ASSOCIATED 

" DOCUMENTATION. 


(*$WIDELIST,N0 MAP , LOCAL S ,GL0BALS*) 

PROGRAM <DUMMY NAME>; 

It 

" ROUTINE NAME: <NAME OF R0UTINE(S)> 

n 

" ABSTRACT <DESCRIBE THE GENERAL PURPOSE OF THE R0UTINE> 

II 

" NOTES: <SPECIAL CONDITIONS, ASSUMPTIONS, OR OTHER SPECIAL 

" INF0RMATI0N> 

" METHOD: <DESCRIPTION OF ALGORITHM IF NECESSARY> 

II 

" REVISIONS: ORIGINAL <MM/DD/YY>; 

" REVISION <INTEGER>: <MM/DD/YY>, <PURP0SE OF REVISION> 

II 

" ENVIRONMENT: 990/10 PASCAL X.X 

" TABLE SEGMENTS MAPPED IN WHEN ENTERED 

" <STA, JCA OR OTHER TABLE> 

" TABLE SEGMENTS MAPPED IN DURING ROUTINE 

" <STA, JCA OR OTHER TABLE> 

(*$PAGE*) 

If 

" GLOBAL DECLARATIONS 


2270512-9701 


3-11 


Coding Conventions 



DNOS System Design Document 


II 

CONST <IDENTIFIER> = <CONSTANT EXPRESSION>; ( *<DESCRIPTION>* ) 

?COPY <FILENAME OF GLOBAL CONSTANTS>; 

TYPE <IDENTIFIER> = <TYPE>; (*<DESCRIPTION>* ) 

?COPY <FILENAME OF GLOBAL TYPES>; 

COMMON <IDENTIFIER> : <TYPE>; ( *<DESCRIPTION>* ) 

?COPY <FILENAME OF COMMONS>; 

ACCESS <IDENTIFIER>, 

<IDENTiFIER>; 

II 

" FUNCTIONS OR PROCEDURES DEFINED EXTERNAL TO THIS MODULE 

II 

<INSERT THE ?COPY THAT BRINGS IN PROCEDURE DECLARATIONS FOR THIS 
SUBSYSTEM, WHERE EACH PROCEDURE IS DEFINED WITH ITS PARAMETERS AND 
DECLARED AS BEING FORWARD>; 

II 

(*$PAGE*) 

II 

PROCEDURE <PROCEDURE NAME)>; 

"<COMMENT HERE THE PROCEDURE NAME WITH ITS PARAMETERS AS A READING AID> 

II 


" LOCAL DECLARATIONS 

II 


LABEL 

<INTEGER>, 

<INTEGER>, 

(*<DESCRIPTION>*) 

(*<DESCRIPTION>*) 


CONST 

<IDENTIFIER> 

= <C0NSTANT EXPRESSION>; 

(*<DESCRIPTION>*) 


<IDENTIFIER> 

= <C0NSTANT EXPRESSION>; 

(*<DESCRIPTION>*) 

TYPE 

<IDENTIFIER> 

<IDENTIFIER> 

= <TYPE>; 

= <TYPE>; 


VAR 

<IDENTIFIER>, 
<IDENTIFIER> , 

<IDENTIFIER> : <TYPE>; 
<IDENTIFIER> : <TYPE>; 


COMMON 

<IDENTIFIER>, 

<TYPE>; 

(*<DESCRIPTION>*) 

ACCESS 

<IDENTIFIER>, 

<IDENTIFIER>, 

<IDENTIFIER>, 

<TYPE>; 

(*<DESCRIPTION>* ) 


II 

II 


BEGIN (*$MAP*) 

II 

-^INSERT PROCEDURE CODE*^ 

II 

END; 

II 

BEGIN (*$NO OBJECT*) 

END. 

Pascal routines make use of the templates in the 

DSC . TEMPLATE . PTABLE directory through use of ?COPY statements. 
The data structure templates are copied in as type declarations, 
and the CSEG template equivalents are copied as common 
declarations. In addition to templates for DNOS structures, the 
DSC . TEMPLATE . PTABLE directory also includes a standard set of 
types for DNOS in D SC . TEMPLATE . PTABLE . TY PES . 
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The PASASM directory includes interface routines written in the 
Pascal .MACROS to allow routines written in Pascal to call DNOS 
kernel routines written in assembly language. Routine names 
begin with the letters PL and have the same last four characters 
as the nucleus routine to which they interface. 

For utilities written in Pascal, a collection of routines is 
available for interface to SCI. These routines are like the S$ 
routines used by assembly language and are found in the Pascal 
object directory. 


3.5 ERROR HANDLING 


Errors detected by assembly language routines are encoded using 
error code constants and equated symbols from the collection 
defined in these copy modules: 


DSC. TEMPLATE .ATABLE .NFCRSH 
D S C. TEMP LATE .COMMON. NFEROO 
D S C. TEMPL ATE .COMMON. NFER 10 
DSC.TEMPLATE.C0MM0N.NFER20 
DSC. TEMP LATE. COMMON. NFER30 
DSC . TEMPLATE . COMMON . NFER40 
DSC. TEMP LATE. COMMON. NFER50 
D SC. TEMP LATE .COMMON. NFER60 
DSC. TEMPLATE. COMMON. NFER70 
D S C. TEMPL ATE. C0MM0N.NFER80 
DSC. TEMPLATE. COMMON. NFER90 
DSC .TEMPLATE . COMMON . NFERAO 
D S C. TEMP LATE. COMMON. NFERBO 
D SC. TEMP LATE .COMMON. NFERCO 
D S C. TEMP LATE. COMMON. NFERDO 
DSC. TEMP LATE . COMMON . NFEREO 
D S C. T EMPL ATE .COMMON. NFERFO 


(for system crash codes) 
(error codes >00 through >0F) 

(error codes >10 through >1F) 

(error codes >20 through >2F) 

(error codes >30 through >3F) 

(error codes >40 through >4F) 

(error codes >50 through >5F) 

(error codes >60 through >6F) 

(error codes >70 through >7F) 

(error codes >80 through >8F) 

(error codes >90 through >9F) 

(error codes >A0 through >AF) 

(error codes >B0 through >BF) 

(error codes >C0 through >CF) 

(error codes >D0 through >DF) 

(error codes >E0 through >EF) 

(error codes >F0 through >FF) 


All SVC error codes and crash codes are documented in these copy 
modules. Errors detected by Pascal routines use the same codes, 
defining constants to have the appropriate error number. The 
meaning of each error code is described in detail in the DNOS 
Messages and Codes Reference Manual . These errors are also 
viewable with the Show Expanded Message (SEM) command. 


3.6 GENERATING NEW ERROR CODES I 

The current set of error codes must be very carefully examined 
when a new error code is added. For SVCs, the new error code 
must not duplicate any previously defined code which might arise 
for that SVC. The DSC . TEMPLATE . COMMON. NFERxx files and the SVC 
code list in the DNOS Me ssag es a nd C odes Refe ren ce Manu a l must be 
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examined. In addition to codes listed explicitly, an SVC 
processor may return an error code defined for I/O SVC 00 if an 
I/O SVC is executed by the processor. Thus, for SVCs in the 
following set, any new error code cannot duplicate any defined 
for SVC 00: >14, >1F, >20, >22, >25, >26, >27, >28, >29, >2A, 
>2B, >31, >34, >37, >38, >40, >43 and >48. The error codes 
reserved for I/O are annotated in the NFERxx files as being used 
for SVC 00, lOU, FILEMGR, DIOU, or IPC. Also, SVC >40 and SVC 
>43 must not share an error code, since SVC >43 returns errors 
from SVC >40. 

Once a new error code has been chosen for an SVC error, that code 
must be documented in the appropriate NFERxx file. It also must 
be documented in the SVC files used by the error processing 
utilities. These files are DSC . MESS AGES . TEXT . SVC and 
DSC .MESSAGES .EXPTEXT . SVC . If the message employs variable text 
pulled from the offending call block, the appropriate entries 
must also be made to the tables in DSC . REQPROC . SOURCE . RPRCDA for 
use by the Return Code Processor SVC. The section on system 
tasks includes a description of the task RPRCP and its required 
data structures for handling the Return Code Processor SVC. 

When adding error codes for non^SVC purposes, several sources 
must be examined. Task errors are documented in the NFERxx files 
as well as in the DNOS Messages and Codes Reference Manual . Any 
additions to the set must not duplicate previously defined codes, 
and appropriate updates must be made to the NFERxx files and the 
manual . 

Additional system crash codes must be checked with the file 
DSC. TEMPLATE .ATABLE.NFCRSH and with the DNOS Messages and Codes 
Reference Manual . Additional error codes for SCI or utilities 
must be checked against currently defined codes as documented in 
the DNOS Messages and Codes Reference Manual . Further 
information about assigning error codes for SCI or utilities can 
be found in the DNOS SCI and Utilities Design Document . 
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SECTION 4 

DNOS STRUCTURE AND NUCLEUS FUNCTIONS 


4.1 OVERVIEW 

DNOS uses the memory mapping option of the 990/10, 990/10A and 
990/12 to efficiently divide the operating system code. It uses 
a number of common data structures and a set of system files to 
facilitate communication between subsystems. The DNOS nucleus 
includes the code for miscellaneous support functions, task 
scheduling and execution, interrupt processing, task termination, 
and SVC processing. 


4.2 SYSTEM MEMORY MAPPING 

Parts of DNOS run in map file 0, some parts run in map file 1 and 
other parts alternate use of each map file. Each map file is 
divided into three segments that may total up to 64K bytes of 
physical memory. 

Task code is executed in map file 1. SVC support, device service 
routines (DSRs), interrupt support, and scheduling code are 
executed in map file 0. Several nucleus support routines may 
execute in either map file (depending on which is in use by the 
caller). Figure 4-^1 shows the arrangements used by DNOS. 

Map file 0 contains the following: si 

* First map segment (system root): 

Interrupt and XOP vectors, interrupt decoder and 
tables 

■*' Nucleus common support routines 
Common data segments 
^ System table area (STA) 

* Second map segment: 

^ Job communication area (JCA) for the task 
currently executing, or 
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^ Special table areas as needed by subsystems, or 
^ Buffers for I/O 
Third map segment: 

Scheduler overlay including some SVC support, or 
■*' SVC support not included in scheduler overlay, or 
^ DSR code as required by devices. 

-- Task code running in a fast transfer mode 


Map file 1 is set up in one of two ways, depending on whether or 
not the task is installed in a program file as a system task. If 
the task is a system task, the first map segment is set up the 
same as map file 0, the second map segment is set up with the JCA 
of the task, and the third map segment is set up with the task 
code. For nonsystem tasks, all three map segments may be used 
for task and procedure code (no system area is mapped into the 
task) . 
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First Segment 


Second Segment 


Third Segment 


-1^ ■4* ifr ^ ^ -J- 

I Kernel Code I 
ISystem Table Area| 


1 5,6 


t, ti- -^- 

1 JCA 1 

I SM Table | 

I FM Table 

*■*•*• + 

I Synonym and Name j 1 
I Segment 1 

4.» ♦♦**♦*.*♦****.♦♦* *+ 

1 Physical Record 1 2 

I buffer 

+ 4 *. ♦ 

*. *. 

I Disk Bit Map j 3,5,6 


I Scheduler /SVC Code I map 0 
5,6 I SVC Code I map 0 



« «■ «-+ 


DSR 




1 System Task Code 


1 map 0 


map 1 
or 0 


IDevice I/O Bufferl 4,5 

-H- * Ik 


1 ^ mapped only by name management 
^ mapped only by file management 
■*' mapped only by disk management 
^ mapped only by DSRs and I/O subsystem 
memory^resident 
6 * fixed size 


Figure 4*1 DNOS Map Files 


4.3 SYSTEM DATA STRUCTURES 

DNOS data structures include both common segments and dynamically 
allocated tables. 

The two common segments that contain most of the system variables 
and pointers are NFDATA and NFPTR. The common segments 
containing most of the constants used in DNOS include: NFWORD, 
NFEROO, NFERIO, NFER20, NFER30, NFER40, NFER50, NFER60 , NFER70, 
NFER80, NFER90, NFERAO, NFERBO , NFERCO, NFERDO , NFEREO , and 
NFERFO . 

See the section on detailed data structures for more information. 
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The four areas from which system data structures may be allocated 
are as follows : 

* STA, in the system root, where structures needed by more 
than one job are located 

* JCAs, one for each job in the system, where job^local 
structures are located 

* Segment Manager special table areas (see the section on 
segment management for details) 

* File Manager special table areas (see the section on the 
I/O subsystem for details) 

Each job in the system is represented by a job status block (JSB) 
in the STA, The JSB contains job identification information, 
links for various queues, and priority information. 

Tasks (programs) executing in each job are represented by TSBs, 
kept in the JCA for the job in which the task is running. The 
TSB contains all of the information concerning the state of a 
task. This includes the current task status indicators of 
workspace pointer (WP), program counter (PC), and status register 
(ST); task state; task priority; flags; installed and run^time 
IDs; segment identifiers; map file registers; outstanding I/O 
counts; execution time; and end-faction pointers for the WP and 
PC , 


4,4 SYSTEM FILES 

DNOS requires certain files to be on the system disk (primary 
disk) for its operation. These files are: 

* The loader file, ,S$IPL, containing the image of the IPL 
program (see the section on IPL and System Loaders) 

* The kernel program file, containing the tasks, 

procedures, and overlays comprising DNOS 

* The utilities program file, containing tasks and 

procedures for system utility programs 

* The applications program file specified in SYSGEN, 
containing tasks and procedures for user programs 

* The shared program file, ,S$SHARED, on which users may 
place procedures to be shared by other program files, 
and where tasks and procedures are placed when installed 
to LUNO 0 
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* The swap file, . S $ ROLLD . S $ROLLA , where task images are 
temporarily placed to make room in memory for higher-*^ 
priority tasks 

* The crash file, .S$CRASH, where an image of memory is 

written in the event of a system crash 

Other files are also on the system disk for proper execution of 
SCI and various DNOS features. These files are: 

* The command procedures directory of SCI commands, 
.S$CMDS 

* The directory of command definition tables used to 
process keyboard bids, .S$CDT, with one file for each 
system booted on this disk 

* The messages directories, .S$MSG and .S$EXPMSG. If 

these are not present, messages appear in cryptic form. 

* The spooler queue directory, .S$SDTQUE, with one file 

for each system booted on this disk 

* The system generation directory, .S$SGU$ 

* The overlay management directory, .S$SYSLIB 

* A library of system programmer commands and the system 
history file in the directory .S$SYSTEM 

* The user ID directory, .S$USER and the capabilities list 
file, .S$CLF 

* Accounting files, .S$ACT1 and .S$ACT2, used when 

accounting is enabled 

* The initialization batch stream .S$ISBTCH, used to start 
the Spooler and for user*specif ied activities 

* System log files, .S$L0G1 and .S$L0G2 

* The file .S$MVI, used by the Modify Volume Information 
processor to record changes to the disk 

* The file .S$SCA, used by LOGON and SCI 

* The program file .S$SECURE, used if file access security 
is generated with the system 

File structures are described in detail in the section on file 
management . 
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4.5 NUCLEUS SUPPORT FUNCTIONS 

The nucleus provides support routines for system tasks as well as 
for other parts of the nucleus. The routines support such things 
as routine linkage, queuing, synchronization, inhibiting 
scheduling, map file changes, table area management, and system 
crash analysis. 


4.5.1 Linkage Support. 

Most of the linkage between DNOS routines is accomplished by the 
push and pop routines (NFPSHn and NFPOPn, where n is the number 
of registers to push or pop). RIO is used throughout the DNOS 
code as a stack pointer. On entry to a routine, the return 
address is pushed on the stack, and a push routine is called to 
save registers on the stack. To exit from the routine, the 
return code is placed in the leftmost byte of RO and a branch is 
made to the pop routine that corresponds to the push routine that 
was used. The assembly language macros SPUSH and SPOP must be 
used to set up the linkage to subroutines, since the performance 
microcode depends on their use. For example, the following code 
shows linkage using three registers: 


Entry: 


Exi t : 


^ ^ ^ 


4(- A- ^ 


MOV 

R1 1 ,*R10+ 

MOVB 

@ERR30 ,R0 

BL 

@NFPSH3 

B 

@NFP0P3 

SPUSH 

3 

SPOP 

@ERR30 


Most of the code in the kernel makes use of the stack defined in 
the scheduler segment. The scheduler stack is initialized at the 
NFSCHD and RPROOT entry points. 

When the called routine makes use of SPOP to return to a caller, 
the calling routine can specify three types of error returns. 
The word following the BL instruction contains a return address 
to be used if an error occurs in the called routine. When the 
called routine branches to NFPOP, a test is made to see whether 
or not the leftmost byte of RO is zero. If it is not zero, the 
return is made to the address specified for error handling. Two 
special cases can be specified as error addresses: 
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* 0 ^ indicates that there is no error possible or that 

the error should be ignored and, if one occurs, return 

to the same address that would have been used if no 

error had occurred 

* -*1 ^ indicates that no error return is expected and if 

one occurs a system crash (0029) should occur, (This 

case is primarily used during debugging of DNOS code.) 


4.5.2 Queuing Support. 

Many of the DNOS system tasks are queue servers, tasks dedicated 
to processing entries on queues. When an entry is placed on a 
queue server's queue, the queue server is activated (if it is not 
already active) and begins processing entries. When the 
processing is finished, the queue server either suspends and 
waits for more entries to be placed on the queue, or it 
terminates; depending upon the time^cri tical nature of the 
function being performed. 

System data structures can be queued and dequeued to the 
following types of queues, using the nucleus queuing routines: 

* Queues with one-^word headers, whose entries form a 
singly linked list. The routines NFQUEl and NFDQl are 
used to queue and dequeue the entries in a first-*'in, 
first^out manner, 

* Queues with a six^word header, whose entries form a 

singly linked list. The header includes fields pointing 
to the first entry and to the last entry, and it 
contains a count of the entries. If the queue is being 
served by a queue server, the header also contains the 
task identifier for the queue server task as well as the 
TSB address, the JSB address, and the program file 
identifier. The routines NFQUEH and NFDQH are used to 
queue and dequeue entries in a first in, first out 
manner. NFQUEH activates the queue server when 

necessary . 

* Queues of overhead beets (OVBs), whose entries form a 
doubly linked list. The routines for queuing and 
dequeuing overhead beets are NFLOVB and NFDLOV memory 
management lists and NFQOVB and NFDOVB for six^word 
headers . 

Queue headers for system queues are maintained in two locations. 
Some queue servers execute in the system job and have their queue 
headers in the system root. Other queue servers execute in the 
user's job and have their queue headers in the user's job 
communication area (JCA). Queue headers are defined with an 
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assembly language DEF directive for the header so that queue 
servers running in the system job can use an assembly language 
REF directive for the label and access the queue header address 
directly. Queue servers in the user's job receive the queue 
header address as their second task bid parameter and access the 
queue header using this address. 

The form of a system queue header is shown in the queue header 
template, QHR. All system root queue headers are defined in the 
template, DSC . TEMPLATE . COMMON . NFQHDR . NFQHDR is copied during 
sysgen to initialize the queue headers. Some of the queues are 
optional, depending upon sysgen choices. If a queue is not used, 
the symbol for the queue header is defined as a word of zeros in 
the system root. The bid of a queue server is done by NFACTQ and 
the queue server terminates after processing the queue of 
reques t s . 

During system start-up, to prevent premature request processing, 
the queue server IDs in several queue headers are temporarily set 
to zero. When the system is ready to handle the requests, the 
queue server ID is restored. These operations are done by 
RESTART. 

Queue headers in the job communication area are built when a job 
is created. The queues for program file SVC operations (install, 
delete, assign space, map name to ID), Initialize New Volume SVC, 
and Return Code Processor SVC are in the user job communication 
area. The section on writing system tasks describes how to build 
tasks for each of these environments. 


4.5.3 Synchronization and Coordination. 

Some nucleus routines aid in coordinating access to the same 
system structure or code by more than one routine. One such 
coordination aid is the door. A door is described by a two-*t^word 
descriptor record that is passed to the door-*^handling routines. 
The routine NFDCLO closes a door and prevents other tasks from 
accessing the door until it is opened by NFDOPN. A task trying 
to access a door that is closed is suspended until the door is 
opened. The macros DCLOS and DOPEN are used to call these 
routines. These macros are in DSC . MACROS . FUNC . (This type of 
coordination may also be accomplished by using the semaphore SVC. 
See the section on program management.) 


4.5.4 Inhibiting Scheduling. 

When a task is executing critical code, scheduling must not 
occur. One assembly language macro is used to inhibit the 
scheduler (INHB) and another to enable the scheduler (ENAB). 
Between the execution of INHB and ENAB, the task will not be 
rescheduled. These macros are located in DS C . MACROS . FUNC . 
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4,5.5 Map File Changing. 

Occasionally, a system task (which normally executes in map file 
1) must call a routine that can execute only in map file 0. 
Interface routines are available for switching to map file 0 upon 
entering a routine and returning to map file 1 upon exit. A 
routine is entered in map file 0 by executing a BLWP @NFMAP0 , 
with the next word of program code specifying the address of the 
routine to be entered. The second word following the BLWP 
contains an error address, zero, or *1. If an error address is 
specified and an error occurs, the return from the called routine 
is made to the error address. If zero is specified and an error 
occurs, no special action is taken; execution continues. If *1 
is specified and an error occurs, the system crashes with a crash 
code of >0029 (this is used primarily during debugging of DNOS). 
The called routine returns to the caller in map file 1 by 
branching to NFRTNO, 

When a routine executes in map 0, it expects to be using the 
scheduler workspace. Thus it is necessary to set up any required 
registers in that workspace before calling NFMAPO . It is also 
necessary to pass back any data, (including any error code in RO) 
before calling NFRTNO. 


4.5.6 Table Area Management. 

The routines in module NFTMGR allocate and deallocate table area 
in the dynamic table areas. Allocation is performed by NFGTA and 
NFGTAO (Initialized to zero after allocation), and deallocation 
is performed by NFRTA. The smallest block of table area 
allocated is eight bytes. When memory in the specified table 
area is exhausted, an error is returned to the caller. Macros 
GTA, GTAO , and RTA must be used to access these routines. These 
routines may not be called from code which processes interrupts 
or requires interrupts to be masked. 

The Segment Manager support routines enable system functions to 
map special table areas, find segment status block (SSB) 
addresses for segments, create and delete SSBs and SGBs, and 
force load segments into memory. Descriptions of these routines 
follow: 
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SMMJCA, SMMJCl, and SMMJC2 

Maps JCAs Into the second segment of the executing task, or 
processor map file. When called from map file 0, each of 
these routines performs the same processing, simply mapping 
the requested JCA into the current map file 0. When called 
from map file 1, SMMJCA does not change the releasable and 
modified status of the old segment. SMMJCl allows the 
caller to specify the releasable and modified status. 
SMMJC2 is used if the caller needs an error code rather than 
loading of the JCA when the JCA is not in memory; otherwise 
SMMJC2 functions like SMMJCA. 

SMMTBL and SMMTBl 

Maps special table areas into the second segment of the 
executing task or processor map file. These two routines 
function like SMMJCA and SMMJCl. 

SMMSEG 

Maps an arbitrary segment into the second segment of the 
executing task map file. SMMSEG allows the caller to 
specify a byte offset which is to be the beginning of the 
mapped portion of the segment. Specifying an offset of zero 
causes the entire segment to be mapped. 

SMCSGO 

Maps an arbitrary segment into the second segment of the 
executing task map file. SMCSGO does the actual work of and 
is a common subroutine of SMMJCA, SMMTBL, and SMMSEG. 

SMSRCH 

Returns an SMT/SSB pair for a specified ID/file descriptor 
packet (FDP) pair. SMSRCH calls SMFSID to see if an SSB 
exists for the specified ID. If so, it verifies that the 
caller has access to the segment, which may include an 
SMCHUC call. If the caller has access, the SMT/SSB pair is 
returned. If not, SMSRCH will return a replicated SSB if 
the segment is repl Icatable ; otherwise an error is returned. 
If no SSB already exists, SMBLDS is called to create one. 

SMBLDS 

Creates an SSB (and an SGB if necessary) for a given segment 
type. The caller specifies an FDP and a task/ procedure 
flag. If the FDP is zero, a memory^based segment is built. 
SMBLDS first builds an SGB if there is none for the 
specified file. It then builds an SSB of the correct size, 
supplies a run-time ID, and links the SSB onto the SGB. For 
data files, the length and attributes are set; for program 
files, certain flags are set. 
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SMFSID 

Searches a segment group for a segment with a specified ID. 
The caller specifies the segment group via an FDP address. 
If the FDP address is zero, the memory^based segment group 
is assumed. The caller can search for the segment via an 
installed or run^time ID. Also, the caller can search for a 
task segment. If a match is found, the Segment Manager 
table area that contains the segment's SSB is mapped. This 
routine is callable by system tasks and processors. 

SMCHUC 

Checks to see if the use counts of a given segment can all 
be accounted for by the mapped or loaded segments of a task. 

SMLOAD 

Loads a segment into memory for system tasks if the segment 
is not already in memory. The segment is not mapped into 
the task address space but remains in memory as long as the 
task is in memory. A segment may be loaded by more than one 
task, regardless of its attributes. The use count and task-*^ 
in*'memory count of the segment are incremented. This 
routine also serves the function of an SVC processor. 

SMUNLD 

Unloads a segment loaded by SMLOAD. SMUNLD detaches the 
segment from the task; consequently, the segment need not be 
in memory when the task is in memory. This routine 
decrements the use and task^^in^memory counts for the 
segment. This routine also serves the function of an SVC 
processor . 

SMDSSB 

Deallocates segment memory and deletes a specified SSB. If 
the segment (specified by the SMT/SSB pair) is not used, 
reserved, or owned and not memory^resident , the SSB is 
eligible for deletion. If the segment is reusable, it is 
left cached. If it is updatable and modified, it is placed 
on the write queue. If the segment is not in memory, the 
swap table entry is released; if in memory, the segment is 
placed on the loader queue for deallocation. The SSB is 
then delinked and released. If no more SSBs exist for the 
associated SGB, SMDSGB is called. 

SMDSGB 

Deletes a specified SGB. SMDSGB verifies that there are no 
more SSBs linked onto the SGB and no LUNOs assigned to the 
associated file, then delinks and releases the SGB. If the 
SGB is deleted, an >A7 call is placed on the lOUQUE to clean 
up the file structures. 
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SMRMVE 

Removes a segment from a task. SMRMVE is called when a 
segment loses its association with a task on the TOL, 
whether because of a segment manager SVC or task 
termination. The task-^in^memory count for the segment is 
decremented and, if it goes to zero, the segment is placed 
on the cache list. SMDSSB is then called to finish 
processing the removal. 

SMFLSH 

Writes cached buffer segments to disk and deallocates the 
memory. SMFLSH processes all segments associated with a 
specified LUNO (JSB/LDT pair). If they are modified, it 
places them on the write queue and waits for the write to 
complete. SMDSSB is called to delete the segment. SMFLSH 
must be called only by task code. 

SMBUFF 

Accesses the SSB address of a buffer in a specified task. 
The caller specifies a JSB, TSB, and buffer address. SMBUFF 
returns the SSB address for the buffer and the offset of the 
buffer into the segment. 

4.5.7 System Crash Routine. 

Whenever an Internal operating system error is detected, a branch 
is made to the system crash routine (NFCRSH), passing a crash 
code indicating the type of error. The crash routine halts the 
system and displays the crash code on the front panel of the 
computer. When the HALT and RUN indicators on the front panel 
are pressed, the crash routine saves the state of the system at 
the time of- the crash and writes an Imag^ of memory to the crash 
file on disk. This crash file may then be analyzed by systems 
programmers . 


4.6 NUCLEUS FUNCTIONS FOR TASK SCHEDULING AND EXECUTION 

The DNOS component that places tasks into execution is the task 
scheduler (NFSCHD). A task must first be bid and activated 
before the scheduler can select it for execution. The scheduler 
selects the highest-prior 1 ty task ready to execute and causes the 
central processing unit (CPU) to start executing it. The task 
then executes for a quantum of time until it voluntarily or 
involuntarily releases control of the CPU. At this point, the 
next task in priority order is selected for execution. The 
execution period may be limited to a value known as a time slice. 
The scheduler also collects the accounting and performance data 
related to CPU execution. 
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The following is a metacode description of the scheduler 
algorithm : 

BEGIN 

IF a task is currently active 
THEN BEGIN 

increment execution time for task; 

IF task is a timesharing task 
THEN BEGIN 

update I/O-bound Indicator; 
recompute run-time priority; 
adjust run-time priority for aging; 

END; 

IF task is to remain active 

THEN requeue task on active queue; 
clear active task; 

END; 

REPEAT 

check for reenter and time-out flags (from DSRs); 

IF DSR task bid is outstanding 

THEN call task bid routine for task; 

IF a time-delayed task needs reactivation 
THEN call activate task routine; 

IF any buffered requests need processing 

THEN call end of buffered request processor; 

IF no task is on active queue 

THEN idle (wait for next Interrupt); 

UNTIL task found to execute; 

set up hi gh es t-p r 1 or 1 ty task for execution; 

IF task needs I/O requests unbuffered 
THEN call unbufferlng processor; 
place task into execution; 

END 


4.6.1 Data Structures. 

The data structures referenced by the scheduler are JSBs and 
TSBs. Each JCA includes a queue of TSBs for tasks ready to 
execute, ordered by execution priority. Each JSB carries the 
priority of the highest-priori ty task on its active queue; the 
queue of JSB 

execution. When a task reaches the end of its allotted execution 
time, its TSB is returned to the JCA active queue if it is to 
remain active; it is left unqueued if the task is to be 
suspended. When a task suspends, it may be necessary to change 
the priority of the hi gh e s t -p r 1 or i t y active task in the JSB and 
reorder the JSB on the system JSB queue. 
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4.6.2 Execution Priorities. 

Every task has three associated priority values: a run-time 
priority, an Initial priority, and an Installed priority. Task 
run-time priorities range from a high of 0 to a low of 255. The 
run-time priority Is used by the scheduler when selecting tasks 
for execution. The initial priority is the initial value of the 
run-time priority and also ranges from 0 to 255. The Installed 
priority is the priority assigned to the task when It Is 
installed in a program file. The calculation of the initial 
priority Is based on the Installed priority, the priority of the 
job In which the task is being bid, and the mode In which the 
task Is being bid (foreground or background). Job priorities 
range from a high of 0 to a low of 31. 

Installed priority 0 Is limited to certain system tasks. An 
Installed priority of 0 always maps to an initial priority and a 
run-time priority of 0. The task's run-time priority does not 
vary during execution. 

Real-time tasks have Installed priorities ranging from 1 to 127. 
The Initial priority of a real-time task Is always the same as 
its Installed priority. The priority of real-time tasks does not 
vary during execution. Therefore, the run-time priority Is 
always equal to the Initial priority and ranges from 1 to 127. 

All other tasks are time-sharing tasks. They have Installed 
priorities of 1, 2, 3 or 4. Installed priority 1 Is Intended for 
highly Interactive tasks. Installed priority 2 Is Intended for 
foreground tasks that are less Interactive. Installed priority 3 
Is Intended for tasks that execute exclusively In background. 
Priority 4 Is intended for use by tasks that can run either in 
foreground or background. Priority 4 Is appropriate for almost 
all user tasks . 

The following discussion of Initial priority mapping and dynamic 
priority modification applies only to time-sharing tasks. 

Each of the four time-sharing task priority classes (1, 2, 3 or 
4) have associated parameters that determine the mapping from 
Installed priority to run-time priority. These parameters can be 
modified with the Modify Scheduler/ Swap Parameters (MSP) SCI 
command. The run-time and Initial priorities for all background 
tasks (regardless of their Installed priority) are calculated 
using the scheduling parameters for priority class 3. 

The first parameter used in calculating a run-time priority Is 
the Initial Priority Mapping Value. The initial priority for a 
task Is a function of the Initial Priority Mapping Value 
parameter, the job priority of the job In which the task is being 
bid, and the Weight of Job Priority parameter. The Weight of Job 
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Priority specifies the range over which an Initial priority can 
vary based on the job priority. For example, assume that the 
task being bid has an installed priority of 4 and that the task 
is being bid in foreground mode. Assume that the Initial 
Priority Mapping Value parameter for priority class 4 is 190 and 
that the Weight of Job Priority parameter for class 4 is 32. If 
the job priority were 0, the initial priority for the task would 
be 190 “ 32 = 158. If the job priority were 31, the initial 
priority would be 190 + 32 = 222. If the job priority were 7, 
the initial priority would be 190 - 16 = 174. The mapping from 
the Initial Priority Mapping Value to the actual initial priority 
is proportional to the job priority, within the range specified 
by the Weight of Job Priority parameter. 

DNOS has optional dynamic modification of priorities. As a time- 
sharing task executes, an indicator shows whether the task is 
I/O-bound or compute-bound. The indicator shows the number of 
suspensions over a fixed time period and is recomputed at the end 
of each execution period for a task. This indicator is used to 
modify the initial priority to create the run-time priority 
(raising it for I/O-bound tasks and lowering it for comput e -bound 
tasks). The variation of the run-time priority from the initial 
priority depends on the Dynamic Priority Range parameter for that 
priority class. A Dynamic Priority Range value of 16 would 
indicate that the run-time priority could differ from the initial 
priority by +/-16. A Dynamic Priority Range of 0 would indicate 
that the run-time priority would never differ from the initial 
priority. 

The default Dynamic Priority Range parameter for all four 
priority classes is 0. That is, dynamic priority modification is 
disabled by default. Performance tests have indicated that 
dynamic priority modification does not improve response time and 
can cause unacceptable deviations in performance between stations 
when the computing environment is characterized by homogeneous 
activity (basically similar tasks executing at most stations). 
However, dynamic priority modification can improve response time 
without causing significant performance deviations in 
heterogeneous computing environments (varied computing activity, 
possibly occurring at irregular intervals). If a system 
administrator wishes to try dynamic priority modification, the 
Dynamic Priority Range parameters should be set to 4, 4, 0,8 using 
the MSP command. Dynamic priority modification can always be 
disabled again by setting the parameters back to 0,0, 0,0. 

The Aging on Priority parameter is a YES/NO value indicating 
whether task aging is used for a given priority class. Task 
aging should only be used for background tasks (priority class 
3). If task aging is in effect, the priority of an older task is 
raised slightly more than the priority of a new task. To raise 
the priority, the power of 4 that represents the execution time 
in seconds is used. A task that has executed for 4 seconds is 
raised 1 priority level, one that executed for 16 seconds is 
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raised 2 levels, etc. Task aging can be disabled by setting the 
Aging On Priority parameters to NO, NO, NO, NO using the MSP 
comma nd • 


4.6.3 Time Slicing. 

Time slicing allows a task to run during a quantum of time and 
then forces the task to release control of the CPU. This Is 
accomplished by an Interface with the clock Interrupt processor. 
The clock Interrupt routine counts the number of clock ticks for 
which a task executes. (A clock*tlck Is 8.33 MS In the United 
States, 10 MS In Europe.) When the count reaches a specified 
number, control returns to the scheduler rather than to the 
executing task. During sysgen, the user can specify the length 
of the time slice or can disable time slicing. The length of a 
time slice can also be changed using the Modify Scheduler /Swap 
Parameters (MSP) command. 


4.6.4 Task B1 d . 

The process of preparing a task for execution Is called bidding a 
task. This Is accomplished by the nucleus routine NFTBID. The 
process Involves building and Initializing the necessary data 
structures, such as the TSB, and activating the task. 


4.6.5 Task Activation. 

The NFPACT routine activates a task. If the task segments are 
already In memory, checks are made to see that the task Is not 
being killed and that Its job Is not terminating; If these 
conditions are met, the task Is put on the active queue. If the 
segments are not In memory (as Is the case following a task bid), 
the task Is put on the wa 1 t 1 ng-on-memo ry (WOM) list to be 
processed by the task loader. (See the section on program 
management for details.) After the task Is loaded Into memory, 
NFPACT Is again called to place the task on the active queue. 

NFPACT calls the routine NFACTL to place a task on the active 
queue. The routine NFDACT removes a task from the active queue. 
The routines NFWOML and NFDWOM place tasks on the WOM list and 
remove them from the WOM list. The routine NFWOMJ places a JSB 
on the WOM list. 

Figure 4-2 shows the flow through the task scheduler. 


4.6.6 Table Area Scheduling. 

If a GTA(O) request falls, NFPWOT may be called to place the 
active task on the Waiting On Table area (WOT) queue. NFPWOT 
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causes the active task's context to be set back as outlined 
below. NFDACT Is called to remove the task from the active list, 
and NFWOTL places the task on the WOT. NFPWOT then returns 
through NFSRTN. 

When any RTA Is executed, the WOT Is examined by NFRTA. If a 
task Is on the WOT, NFWAKE Is called to restart the task. NFWAKE 
calls NFDWOT to remove the first waiting task from the WOT and 
makes It active. 

NFPWOT makes certain assumptions about the environment In which 
the GTA(O) was Issued. If the GTA(O) was Issued from Map 1 
(task) code, NFPWOT expects entry through the GTA(O) error 
return. The restart context will be set back to the GTA(O) XOP 
which will be reissued when the task Is restarted. If the GTA(O) 
was Issued from Map 0, NFPWOT assumed the failure occurred while 
processing an SVC. In this case the active task's context Is set 
back to reissue the SVC. This means only modules which process 
SVC's may call NFPWOT from Map 0. It Is also necessary for the 
SVC processor to restore all system structures to the state they 
were In before the SVC was Issued as It will be reprocessed 
ent Irely . 
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Figure 4-2 Flow of Control in Task Scheduling 
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4.7 INTERRUPT PROCESSING 

When an interrupt occurs, it is processed by the anpropriate 
interrupt processor. When the interrupt processor is finished, 
it branches to a return routine (NFTRTN), which returns to either 
the interrupted code or to the scheduler if the time slice for 
the task has expired. 


4.7.1 Clock Interrupt Processor. 

NFCLOK, the clock interrupt processor, gathers performance 
statistics, keeps track of time, and decides when a time slice 
occurs. The time and date are kept in the following form: year, 
day (Julian), hour, minute, second, and tick. Also, a 32-blt 
tick counter keeps track of time in clock ticks. The time, the 
date, and the tick counter are updated each clock tick. The tick 
counter counts clock ticks for 14 months before returning to 
zero; it is used for timing system functions such as task time 
delays. (A clock tick is 8.33 ms in the United States, 10 ms in 
Europe.) 

Statistics gathering involves sampling a set of flags. The flags 
may be set and reset by the operating system at the beginning and 
end of critical functions. The frequency with which a flag is 
set determines the percentage of time that the operating system 
spends within the section of code between the set and reset. A 
variable contains the number of flags to be sampled; a two-word 
counter counts the number of times that the flags are sampled. 
Each flag is a full word and is followed by a two-word counter. 
The counter is incremented each time the flag is found to be 
nonzero. The first two flags, representing the CPU and disk 
utilization, are displayed as a bar graph on the front panel, 
with CPU utilization in the leftmost eight lights and disk 
utilization in the rightmost eight lights. This can be changed 
using the System Configuration Utility. The remainder of the 
flags are defined to measure other aspects of system performance 
as shown by the Execute Performance Display (XPD) command. 


4.7.2 Internal Interrupt Processor. 

An internal Interrupt (Interrupt level 2) is caused by 
instruction execution errors (for example. Illegal opcode. 
Illegal memory address, or privileged Instruction). Internal 
Interrupts are processed by the Internal interrupt processor, 
NFINT2. If the interrupt occurs in task code, the task is killed 
or placed into end-action code, and control returns to the 
scheduler. If the Interrupt occurs in operating system code, in 
interrupt processing code, or while scheduling is inhibited, the 
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system crash routine Is called. 


4.7.3 Power-Up and Power-Down Interrupt Processors. 

When a power-down Interrupt (Interrupt level 1) occurs, the 
power-down Interrupt processor (NFPWDN) Idles and waits for the 
power-up Interrupt (Interrupt level 0). When the power-up 
Interrupt occurs, the power-up processor (NFPWUP) chains back 
through contexts saved by Interrupt processors (Interrupts are 
not reentered after power up) to find the noninterrupt code that 
was executing at the time of power down. When the code Is found, 
the map files are set up for that code, the devices are all 
reinitialized by entering each DSR at Its power-up entry point, 
the microcode Is reloaded by calling NFLWCS , and the code Is 
restarted . 


4.8 SVC PROCESSING 

When a task Issues an SVC, the SVC runs with scheduling Inhibited 
until It either completes or suspends the task that Issued the 
SVC. The requesting task Is suspended If completion requires a 
task driven SVC processor. 

When an SVC processor terminates. It may reactivate the calling 
task by branching to NFTRTN. NFTRTN either reactivates the task 
or. If the time slice has expired, forces rescheduling. SVC 
processors that suspend the executing task and wish to return to 
the scheduler do so through the scheduler return routine, NFSRTN. 
NFSRTN saves the status of the executing task In Its TSB and 
exits to the scheduler. 

I/O requests and buffered SVC requests usually require 
unbufferlng of Information to the requesting task when the 
request completes. Unbufferlng must occur when the task Is In 
memory. This Is accomplished by queuing the buffered request 
block (BRB), using NFEOBR, to the TSB If the TSB Is In memory and 
to the JSB If the TSB Is not In memory. The task may then be 
activated. Queued BRBs are unbuffered when the task Is selected 
for scheduling. 


4.9 TASK TERMINATION 

Task execution is terminated when the task Issues a termination 
SVC, another task Issues a Kill Task SVC, or the task aborts by 
executing an illegal or privileged Instruction. Task termination 
Is processed by NFTERM. If the task is not terminating normally, 
NFTERM builds a diagnostic packet and. If the task Is active 
(executable) and has specified end-action (execution after 
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termination), NFTERM restarts the task at the end-action address. 
The diagnostic packet Includes the task program counter, 
workspace pointer, status, task termination error code, and the 
time by which the task must finish end action (see the DIA 
template in the section of data structure pictures). 

End action can continue for no more than five seconds, unless the 
Modify Scheduler / Swap Parameters (MSP) command is used to change 
the limit 

If the task is terminating normally or did not specify end- 
action, NFTERM deactivates the task (if active), places a task 
termination entry on the accounting queue, then releases the 
memory used by the task and system structures that describe that 
memory by calling NFDTOL and NFDTSK. Finally, if the task was 
not restarted, an entry is placed on the task termination queue 
to be processed by the termination processor task, PMTERM. (See 
the section on program management.) 


4.10 SPECIAL COPY ROUTINE 

The routines in the module NFCOPY are used to copy blocks of data 
from one segment to another. There are three main entry points, 
NFCOPY, NFXCPY, and NFCXFR. NFCXFR is used to copy large blocks 
of data from one place to another within the current map file. 
It can be used in either map file 0 or map file 1. NFCOPY and 
NFXCPY are used to copy data from one segment to another where 
neither of the blocks need be mapped. NFXCPY must be called from 
map file 0 and NFCOPY must be called from map file 1 through the 
NFMAPO Interface. NFCOPY calls NFXCPY which then calls NFCMAP to 
set up a special map file which is used for a call to NFCXFR. 
The routine NFCMAP can be called to set up map files for special 
purposes by other routines which run in map file 0 and are 
located in the system root. 
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SECTION 5 

IPL AND SYSTEM LOADERS 


5.1 IPL SEQUENCE 

The DNOS initial program load (IPL) process consists of several 
logi cal steps : 

1. A read-only memory (ROM) loader on the CPU loads the 
track 1 loader (a simple bootstrap program). 

2. The track 1 loader loads the system loader. 

3. The system loader loads the operating system and any 
memory-resident tasks from the user's application 
program file. 


ROMs are discussed in other documents about the 990 computer. 
See, for example, the Universal ROM Loader User's Manual . 

After being loaded, the track 1 loader relocates Itself to the 
last 8K bytes of the first 64K bytes of memory and then reads the 
disk volume information from track 0, sector 0. From this 
Information, the track 1 loader determines whether it is to load 
a diagnostic (stand-alone) program, a secondary loader, or an 
operating system. The file to be loaded may be either an image 
file or an object (compressed or noncomp res s ed ) file. After 
determining what is to be loaded, the track 1 loader loads the 
program into a portion of the first 64K bytes of memory, starting 
at address >A0. Note that this loader cannot load any program 
larger than 54K bytes. 

The system loader loads DNOS from the kernel program file, using 
the steps shown in Table 5-1. 

After the system is loaded, the loader passes control to the 
power-up interrupt handler of the loaded operating system. 

The following paragraphs describe in more detail the operation 
and logic of the DNOS system loader, as well as the data 
structures used by the loader. 
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5.2 SYSTEM LOADER OVERVIEW 

The system loader resides on disk In an Image file called 
DSC.S$IPL and Is loaded Into memory by the track 1 loader. It Is 
linked as If It were a system task; that Is, It expects to be 
mapped In with the operating system root and a JCA while 
executing. This allows the loader to call subroutines In the 
root after the root has been loaded Into memory. The loader 
executes with Interrupts masked to level 2, Inhibiting Interrupts 
f rom devl ces . 

Once loaded Into memory, the loader enables mapping, creating for 
Itself a two-segment map file. The first segment contains the 
loader code, which Is located In the first 8K bytes of physical 
memory. The second segment maps In the 8K bytes of physical 
memory Immediately following the loader code. 

The first section of code (located In module SLIPL) Initializes 
physical memory to reset any correctable memory errors and to 
determine the actual size of physical memory. This procedure 
Involves writing to each word mapped Into the second segment, 
changing the map file to map In the next 8K bytes, and writing 
Into each word In that segment. This process Is repeated until 
the loader tries to write to memory that does not exist. 

Having found the end of physical memory, the loader maps In the 
last 16K bytes as Its second map segment and relocates Itself to 
that segment resetting Its map file such that the first map 
segment maps In the memory starting at physical address 0 and 
logical address 0, and the second map segment maps In the memory 
containing the loader code, starting at logical address >C000. 
From this point on, as the loader finishes a particular phase of 
the load process. It displays the phase on the front panel 
lights, starting at the left. Table 5-1 lists the different 
phases and Indicates the significance of each. 
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Table 5-1 System Loader Phases 
Phase Description 


1 Successful relocation of the loader 

2 Successful open of kernel program file 

3 Successful load of root, verification of 

system version, and load of writable 
control store (WCS) 

4 Successful load of special table areas 

5 Successful Initialization of system overlay 

table and crash file 

6 Successful load of JCA segments 

7 Successful load of DSRs and scheduler 

8 Successful load of memory resident system tasks 

9 Successful load of memory-resident user tasks 


Next, the loader Initializes Its load device (disk drive) for 
I/O. It then determines whether the machine being loaded Is a 
990/ 12 . 

The system root, consisting of a procedure and a task segment 
from the kernel program file. Is then loaded into memory, 
starting at location 0. The loader creates a new three -segment 
map file, mapping In the root as the first segment, the following 
physical memory (up to address >0000) as the second segment, and 
the loader code as the third segment. As soon as the root is 
loaded, the loader verifies that the loader file (.S$IPL), the 
kernel program file, and the utilities program file (.S$UTIL), 
are all of the same version. Then the loader checks the volume 
Information from the disk being loaded to see If a writable 
control store (WCS) file Is specified. If so, it then loads the 
WGS from the file. 

Next, the loader loads or creates the memory-based segments of 
the operating system. The loader traverses the memory-based SSB 
list located In the STA. Each SSB represents a file management' 
or segment management table area and indicates whether to load a 
segment from the kernel program file or to build a segment in 
memory (a nonzero SSBADR value indicates that the overlay Is to 
be loaded from the kernel program file). After loading or 
creating a segment, the loader Initializes that segment's 
overhead words. 
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The loader then performs the following: 

* Determines which of the disk drives defined is the disk 
from which the system was initially loaded and marks it 
as the system disk 

* Installs the system disk 

* Initializes the system overlay table 

* Builds the file structures for the swap file and the 
crash file 

After all of the special table areas are in memory, the loader 
scans the JSB list in the system table area. Each JSB points to 
an SSB for a JCA that needs to be loaded from the kernel program 
file. JCA segments may also require name segments; if so, the 
loader creates the segments. Table management overhead words are 
Initialized in both JCA and name segments. 

The next phase consists of loading the DSRs, the scheduler, and 
the SVC processor segments. The map files of these various 
segments, which are in an array for the scheduler and in the 
physical device tables ( PDTs ) for the DSRs, contain the Installed 
IDs of the overlays on the kernel program file. The loader scans 
the map files, loading any segments indicated. 

The loader then reads the memory-resident system task bit maps 
from the kernel program file and the utilities program file, 
loading each task Indicated. Any associated procedures are also 
loaded. SSBs are created and initialized for all segments loaded 
in this phase. If a user application program file was specified 
during sysgen, the loader reads the bit map for that file and 
I loads all memory-resident tasks, procedures, and segments. 

I The next step in the load process is installing all on-line disk 
volumes. Installing a volume Includes Initializing PDT 
information, creating an FDB for VCATALOG for that disk, and 
Initializing the disk manager data structures. 

The final phase of the loader execution allocates the buffer 
table area (BTA), loads the I/O utility task, and initializes the 
system anchor for BTA. BTA is located in user memory, 
immediately following the memory-resident portion of the 
operating system and all memory-resident tasks. The I/O utility 
task is then loaded, and the system anchor is initialized for the 
file memory list. The memory containing the loader is part of 
user memory. After the initialization is performed, the loader 
transfers control to the power-up interrupt processor of the 
operating system. 
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5.3 SYSTEM LOADER DATA STRUCTURES 

Since the data structures created by the system loader are also 
used by other parts of the operating system, the data structures 
themselves are not described in detail. The loader's use of 
these structures and the reasons for their existence are 
described in the remainder of this section. The descriptions 
assume that the load medium is a disk. In the loader modules, 
device-dependent code is localized to as few modules as possible. 
As a result, the loader is easily configurable as a download 
program that uses a communication port as its load device. 

The system loader uses the following data structures on the disk: 

* Volume information (track 0, sector 0) 

* Volume directory (VCATALOG) 

* Kernel program file, named during sysgen 

* Utilities program file, .S$UTIL (or a name chosen by the 
user ) 

* Shared program file, .S$SHARED 

* Application program file 

* Writable control store (WCS) file 

* Partial bit maps (while Installing the disk) 

All except the volume information and the WCS file are standard 
structures, as described in the section on data structure 
pictures . 

In addition, the system loader uses modules SLDATA and SLDISK for 
Internal working storage. These storage areas are part of the 
system loader object itself, and are available to the system 
loader for the duration of its execution. 


5.3.1 Disk Volume Information. 

The volume information contains the following data used by the 
sy s tern loader : 

* Starting allocatable disk unit (ADU) of VCATALOG, the 
volume directory 

* Names of the following files: 

- kernel program file 
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- utilities program file 

- WCS file (If the Performance Package Is present) 

* Total number of ADUs on the disk 

* Starting sector of the partial bit maps 

* Volume name 

* Number of sectors per ADU on the disk 

5.3.2 WCS File. 

The WCS file Is an Image file whose content Is of the following 
form : 

* Word 1 “ number of bytes of overhead 

* Word 2 - microcode word size 

* One or more repetitions of 

- Word 3 - microcode starting address 

- Word 4 - number of microcode words 

- Microcode 


5.3.3 Kernel Program File. 

Although the kernel program file Is standard In format. Its 
contents are slightly unusual. The kernel program file Is 
created by the Assemble and Link Generated System (ALGS) portion 
of sysgen and contains all of the system segments that are 
configurable during sysgen. The file contains the following: 

* System root (two procedure segments) 

* System JCA (overlay) 

* First segment management table area (overlay) 

* All DSRs Included during sysgen (overlays) 

* Configurable system tasks (starting with task ID 2) and 
their overlays 

* JCAs for sy sgen-def 1 ned jobs (overlays) 
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5.3.4 System Loader Internal Working Storage. 

The modules SLDATA and SLDISK contain the following data Items 
local to the system loader. 

* SLDATA 

- System loader MAP files 

- Linkage to system file structures 

- Memory management and allocation Information 

* SLDISK 

- Disk Initialization routine (SLINIT) workspace 

- Disk I/O routine (SLDIO) workspace 

5.4 FLOW OF CONTROL THROUGH THE SYSTEM LOADER 

SLIPL Is the main routine of the system loader. It Includes the 

loader relocation code and calls to subroutines that perform all 

of the actual loading. Figure 5-1 shows the calling 
relationships between the different loader modules. 
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Figure 5-1 System Loader Subroutine Calls 


5.4.1 Relocating the Loader. 

As described In the overview of the system loader, the first 
activity of SLIPL is to determine the size of physical memory. 
This Is accomplished by using a second map file segment (the 
first segment maps in the loader code). Initially, the loader 
map file maps memory as shown: 
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1st segment 2nd segment 

H — — — — — I-—-,-. — — — — — — j 

ill \ 

I loader | 8K bytes | / 

III \ 

+ + + / 

0 

The memory initialization code then writes to every word in the 
second map segment, comparing the contents of each word after the 
write to verify that the contents are the same. If the 
comparison falls, the loader assumes that it is at the end of 
physical memory. 

After 8K bytes have been checked, the loader resets Its map file 
as shown : 

1st segment 2nd segment 

^ 4. ——— — — — — — — — —f ——— ——— — — — —— -f ————— / 

I I I I \ 

1 loader | 8K bytes | 8K bytes | / 

I I I I \ 

+ + + + / 

0 

This process Is repeated until the end of physical memory Is 
found . 


NOTE 

If the computer being loaded contains the 
maximum amount of memory allowed, or If the 
search for the end of memory causes the 
loader to write to the TILINE peripheral 
control space (TPCS), the write/compare test 
will fall on the first write to the TPCS; 
thus, no accidental TILINE commands can be 
Issued. (TILINE is a registered trademark of 
Texas Instruments Incorporated.) 


After finding the end of memory, SLIPL relocates the loader to 
the upper 16K bytes of physical memory, mapping memory as shown: 
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the CPU 
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it as CPUID In 


NFDATA. 


5.4.2 Load Device Initialization. 

SLINIT has two entry points, SLINIT and SLIVSU. SLINIT performs 
some device Initialization, dependent on values found In the 
loader ROM workspace (location >80 through >9E), and Is called by 
SLIPL. SLIVSU Is an entry point used by the disk Installation 
routine, SLIV, to gather the information about a disk drive 
necessary to Install the volume. The device Initialization logic 
consists of performing a Store Registers command to the disk 
drive and then reading the volume Information (track 0, sector 
0). From this Information, SLINIT Initializes the workspace used 
by the disk I/O routine (SLDIO), saves the important file names, 
and saves the ADU address of VCATALOG. Since the device 
Information Is saved In common segments. It Is accessible by the 
other loader routines. 


5.4.3 Opening a File for I/O. 

Before loading the system root, SLIPL calls SLOPEN to open the 
kernel program file for I/O. SLOPEN Is an Important routine In 
the loader; It accepts as Input a file name, which Is assumed to 
be cataloged In the volume directory VCATALOG. It then 
calculates the hash value of the file name and searches VCATALOG 
for the File Descriptor Record (FDR) for that file. When the 
file Is found, SLOPEN reads the FDR Into the loader's internal 
buffer (located after the last module In the loader) and then 
builds a file control block (FOB) and file descriptor block (FDB) 
for the file. The FCB and FDB are built In the file manager 
table (FMT) If the FMT has been loaded, otherwise, they are built 
In a temporary area In one of the loader common segments. The 
FCB Information is used by the program file I/O routine, SLPFIO, 
to read and write to the file on disk. 
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NOTE 

The loader Is designed so that It can perform 
I/O to only one file at a time; In other 
words, only one file can be open at a time. 


5.4.4 Loading the System Root. 

After the kernel program file Is open, SLIPL loads the system 
root. It calls the module load routine, SLLMOD, to load 
procedure 1 and procedure 2 from the kernel program file. These 
two modules are loaded In adjacent memory, starting at location 
0, and combine to form the system root segment. After the root 
Is loaded, SLIPL resets Its map file to be a three-segment map 
file. It maps the root as the first segment, the physical memory 
Immediately following the root as the second segment, an the 
loader code as the third segment, as shown; 


1st segment 

2nd 



3rd segment 

+ 

+—————- 

“+ II 

+- 

+ 

1 system 

1 

1 W 

1 

1 

1 root 

1 

1 // 

1 

loader | 

1 

1 

1 w 

1 

1 

+ 

,+ 

-+—————/ / — — — — - 

+- 

+ 

0 

JCASTR 

>0000 


end of memory 

loading the 

root , 

SLIPL calls 

SLVRFY 

to verify that the 


versions of the kernel program file, the utility program, and 
S$IPL match. 


5.4.5 Loading a Module. 

The loader calls SLLMOD to load a segment (task, procedure, or 
overlay) from the currently open program file. The module Is 
always loaded Into memory, starting at the next available beet 
address. (A beet address Is an address evenly divisible by 32.) 
Memory Is allocated linearly from physical location 0 to the end 
of memory. SLLMOD Is used for three purposes; 

* Loading a kernel segment (a segment that Is not a system 
or user task, such as a JCA or a DSR) 

* Loading a task or procedure segment 

* Reading the program file directory Index (PFI) for a 
segment 
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When loading a kernel segment , SLLMOD does not create any system 
overhead (such as an SSB or OVB for the segment). It does, 
however, make an entry in an Internal table to indicate which 
kernel segments have already been loaded. Thus, if a segment is 
requested more than once (as is the case for the system JCA) it 
will be loaded only once. This Internal table has the following 
f orm : 


0 i type I ID I load beet | seg. length | 

+ + 

1 I I I I 

. + + 

. // // // // 

. + + 

n I I I I 

+ + 


Each table entry is three words long and contains four fields as 
follows 

* The first byte of the first word is the segment type 
(0=task, 4=procedure, 8=overlay) on the program file. 
Note that a segment Installed as a procedure or a task 
on the kernel is not necessarily loaded into memory as a 
procedure or task. The system root is an example of 
this. 

* The second byte of the first word is the Installed ID on 
the program file. 

* The second word is the beet address where the segment 
was loaded . 

* The third word is the byte length of the segment. 

When a kernel segment is requested, SLLMOD first searches the 
table to determine if the segment is already loaded; if so, 
SLLMOD immediately returns the load beet and segment length to 
the caller. 

If the segment requested is a task or procedure segment, SLLMOD 
loads the segment and builds system overhead for it (SSB and 
OVB). Before trying to load the segment from the program file, 
SLLMOD calls a routine in the system root, SMFSID, to search the 
SSB group for the SSB of the currently open program file. If the 
SSB is found, the segment is already in memory and need not be 
reloaded; otherwise, the segment must be loaded. 


IPL and System Loaders 


5-12 


2270512-9701 



DNOS System Design Document 


5.4.6 Initializing the Crash File. 

After the system root is loaded, SLIPL calls SLCRSH to Initialize 
the crash file information in the system root. This information 
is kept in the CSEG NFDATA and consists of the TILINE address; 
the head, cylinder, and sector addresses of the crash file; and 
the size of the crash file (in' beets). SLCRSH obtains the 
Information by opening the file and extracting information from 
the FDR for the file. 


5.4.7 CPU Type Dependent Initialization. 

After the load device is Initialized, SLIPL determines the CPU 
type. This is done by examining a CRU location. If the CPU is a 
990/10 or a 990/10A, no special initialization is done. If the 
CPU is a 990/12, SLWCS is called to load the WCS file if one is 
specified in the volume information. If the CPU is an S300, the 
clock handler is Initialized for a 50hz clock. 


5.4.8 Loading the Special Table Areas. 

The special table areas for segment management, file management, 
and system common are represented by SSBs in the memory-based 
segment group, located in the STA in the root. These SSBs, built 
during sysgen in the $BL0CK module in the D$S0URCE file, can be 
Initialized with either of the following formats: 

* The beet address field of the SSB contains an overlay ID 

* The beet address is 0 and the length field contains the 
length of the segment to be created. 

Only the first segment management table area SSB and the system 
common SSB are of the first format; none of the others represent 
actual program file segments. 

If the table area is a segment in the program file, it is 
constructed during sysgen to Include only the defined data area, 
thus occupying less disk space than if free area was also 
allocated. The SSB for the table area contains the correct 
length in the SSBLEN field. SLLMOD allocates the difference 
between the SSBLEN value and the segment Installed length as free 
table area. When the system loader loads one of these segments, 
it adds the size of the free area to the memory already allocated 
for the segment; the result is a segment in memory that Includes 
all of the free area. 

If the segment has no program file image (it is completely empty 
and so sysgen built only an SSB for it), SLTABL allocates the 
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amount of memory Indicated in the length field of the SSB; SLTABL 
then initializes the table area management overhead words in the 
segment to indicate that it is completely empty. 


5.4.9 Loading the JCAs. 

The SSBs that represent JCA segments are also in the memory-based 
segment group but are not located in the STA in the root. They 
are located in the first segment management special table area, 
which is built during sysgen and loaded in the preceding phase of 
the system load. To load the JCAs into memory, SLIPL calls the 
routine SLJCA. This routine scans the JSB list, maps in the 
segment management special table area and then uses the SSBADR 
field to indicate which segment is to be loaded. SLJCA never 
creates a JCA segment, since they are all built during sysgen and 
have a segment in the kernel program file. 


NOTE 

Normally, JCA segments are considered 
swappable (except for the system JCA). 


As SLJCA loads each JCA segment, it inspects the job information 
table (JIT) in the JCA to see if any name segment must be created 
for the job. This is indicated by a nonzero value in the SSB 
address field for the segment. If the value is nonzero, it is 
used as the size of the area that must be created. SLJCA creates 
an empty segment and Initializes it as a name segment. (For 
details, see the description of name management in the section on 
the I/O subsystem.) 


5.4.10 Loading the DSRs. 

The next phase of the load process is the loading of the DSRs, 
the scheduler, and the SVC processor segments. The routine SLDSR 
loads these. SLDSR first loads the scheduler and SVC processor 
segments, then the DSRs. It determines which segments to load by 
Inspecting the map files for the scheduler and DSRs, 

The s chedul er / S VC map files are in an array located in the STA in 
the root. The array begins with the scheduler map file, and 
MAPSHD in the NFPTR common segment in the root points to the 
array. Each entry in the array is a six-word map file. 
Initialized during sysgen as follows: 

1. Limit 1 is set to the length of the root. 

2. Bias 1 is set to 0. 
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3. Limit 2 Is set to >4000 (one's complement of >0000), 

4. Bias 2 Is the overlay ID of the system JCA. 

5. Limit 3 is set to the negative value -1, (This Is a 
signal used by IPL to determine whether or not the DSR 
map file has been Initialized.) 

6. Bias 3 Is the overlay ID of the scheduler or SVC 
segment to be loaded. 


SLDSR inspects each map file, loading the segments Indicated by 
the bias 2 and bias 3 fields and initializing each map file with 
the correct bias and limit values. 

After the map file array has been processed, SLDSR scans the PDT 
list, loading the segments Indicated by the map file in each PDT. 
The PDT map files are Initialized In the same way as the 
SVC/ schedul er map files, with the value in bias 3 being the 
overlay ID of the DSR for the device. 


5.4.11 Loading Memory-Resident Tasks. 

After all of the JCAs are In memory, SLIPL Is ready to load all 
of the memory-resident tasks for the system and for user jobs. 
SLIPL first calls SLSTSK to load all of the tasks defined In the 
system job. SLSTSK calls SLMRES to load all memory-resident 
tasks on the kernel program file. SLSTSK then opens the utility 
program file and calls SLMRES to load all memory-resident tasks 
In that program file. SLIPL calls SLUTSK to load user-defined 
tasks from the user's application program file. SLUTSK operates 
In the same manner as SLSTSK. 


5.4.12 Disk System Initialization. 

SLIPL calls SLDINT to perform some system disk initialization. 

SLDINT performs the following functions: 

1. Searches the PDT list for the disk PDT, which 
represents the disk from which the system was loaded. 
This PDT Is then marked to be that of the system disk 
by setting the system disk flag and setting the pointer 
SYSPDT to point to the PDT. 

2. Opens the system swap file by calling SLOPEN. 

3. Installs the system disk volume by calling SLIV. 

4. Initializes the system overlay table used by the system 
overlay loader. 
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5. A. 13 Installing Disk Volumes. 

The next phase of the system loader Is the Installation of all 
disk volumes that are on-line during IPL. To do this, SLIPL 
calls SLIV, which scans the PDT list In the STA, searching for a 
disk. 
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SECTION 6 

SVC REQUEST PROCESSING 


6.1 OVERVIEW OF SVC PROCESSING 

In the 990 hardware architecture, 16 levels of extended 
operations (XOPs) are defined. Level 15 is reserved for use as 
an Interface between user software and operating system services. 
This Interface Is named the Supervisor Call (SVC) Interface. 

When an SVC Is Issued, the 990 computer hardware transfers 
control to a software routine, which begins decoding and 
processing the SVC. The activity of the decoding routine varies, 
depending on the particular SVC request. Some SVCs are processed 
quickly, with little Information passed from requester to 
processor. Other SVCs require extensive effort and time or 
require much Information transfer between requester and 
processor. To allow optimum use of the 990 resources, an SVC 
that requires much time to process Is copied Into a block of 
system table area (STA) along with information Identifying the 
requester; then the requester task Is suspended and Its memory Is 
relinquished to other tasks. 

The amount of effort Involved plus several other factors 
determine the method used by an SVC processor. The SVC request 
is copied (buffered) Into registers if the processor meets the 
following conditions: 


* It Is a memory-resident processor 

* It completes processing of the SVC in a short period of 
time 

* It processes an SVC that may be issued by any task 

* It processes an SVC that cannot be an Initiated event 
( us 1 ng SVC >41) 

* It returns all results directly to the requester task 
space 

Otherwise, the SVC request is buffered into the STA. 

While a task Is having an SVC decoded, that task cannot lose Its 
time slice or be preempted by the scheduler. When the SVC Issued 
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Is one that finishes quickly, the request is decoded and is 
processed, and control returns to the requester task before the 
scheduler can schedule another task for execution. Essentially, 
the sequence of events is as follows: 


1. Requester task Issues the SVC by using XOP @block,15 
(or equivalent) 

2. Decoding routine is entered from the XOP Interface 

3. Decoder determines that this is a request which 
finishes quickly 

4. Decoder copies some or all of request block into 
processor routine registers 

5. Decoder transfers control to processor 

6. Processor performs requested service and returns 
information to requester task 

7. Processor returns control to requester task 


If the SVC request issued is not a fast request, the SVC decoder 
copies the request block into a buffer in STA and then follows 
one of two possible paths. For requests that require much time 
and effort, usually the request Is queued to a processor task and 
the requester task Is suspended until the request completes. 
Processors that are disk-resident tasks follow this path. Such 
processors are either seldom used or very large In size. 

Certain special processors, such as those for I/O and job 
management use an alternate path for processing buffered 
requests. Some preprocessing Is required before control goes to 
a processing task. When following this path, the decoder copies 
the request block Into a buffer In STA or JCA and transfers 
control to the preprocessor. The preprocessor examines the 
buffered request and performs whatever processing It can. For 
some subopcodes, all processing Is completed In the preprocessor. 
In these cases, control Is returned to the requester task. In 
other cases, the preprocessor queues the request to the processor 
task and suspends the requester task. 

When the requester task Is suspended while the SVC is being 
processed, the requester task may be removed from memory to make 
room for another task. When the SVC request is finished, the 
buffered request must be returned to the requester task; then the 
requester task can again be scheduled for execution. To allow 
this, the SVC processor queues the finished buffered request 
block to the requester task's TSB (or to the task's JSB if the 
TSB is not in memory). When ready for a new task, the scheduler 
examines these blocks, ensures that the task Is In memory, calls 
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a routine to return information to the task, and schedules the 
task for execution. 

The decoding routine examines the SVC request not only to 
determine whether processing will be fast or slow, but also to 
verify several other characteristics. Some SVC requests must be 
aligned on a word boundary In order to execute properly. This Is 
the first characteristic the decoder checks for. If the request 
block Is not aligned but should be, an error code of >F1 Is 
returned In the return code field of the request block, and the 
requesting task resumes control. 

Another characteristic to be checked Is the privilege level of 
the request. Some SVC requests can only be Issued by operating 
system tasks. If this requirement Is not met, an error code of 
>F2 Is returned In the return code field of the request block, 
and the requesting task resumes control. Some SVC requests 
require that the requesting task be Installed as software 
privileged. If this requirement Is not met, the task receives an 
error code of >F3 , and the requesting task resumes control. 

Since some of the SVC requests (and their processors) are 
configurable when a DNOS system Is generated. It is possible for 
a task to Issue an SVC that is not supported on a particular DNOS 
system. When this occurs, an error code of >F0 Is returned to 
the request block, and control returns to the requesting task. 
This error code is also returned when a request specifies an SVC 
code that Is not defined In the DNOS set. 

Some DNOS users extend the capabilities of the operating system 
by adding their own SVC codes and processors during sysgen. 
(Such user-defined SVCs have operation codes >80 or greater.) 
The same checks are performed on user-defined SVCs as on the DNOS 
SVCs, and the same set of error codes Is used for these checks. 


6.2 MODULES USED FOR REQUEST PROCESSING 

Most of the routines for processing SVC requests are written In 
990 assembly language; several are written in Pascal. The 
routines are found in modules either in the subsystems that they 
directly support, or in the DSC.REQPROC directory. Modules In 
REQPROC support the decoding, buffering, and unbufferlng of 
requests and also process some of the requests that do not belong 
In any other DNOS subsystem. Table 6-1 lists and describes some 
of the request processor modules found In the REQPROC directory. 
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Table 6-1 Major Request Processor Routines 
Name Description 


RPBUF Routine that copies request blocks to buffers In 
STA 

RPCONV Processors for SVC 0A,0B,0C,0D (data conversion) 
RPDQUE Routine that dequeues and unbuffers SVC requests 
to requester tasks 

RPGSVC Processors for SVC 02 , 03 , 06 , 07 , 09 , OE , 1 1 , 2E , 2F , 35 , 
3B,3E (miscellaneous general -support SVCs) 

RPIDSC Processor for SVC 38 (Initialize New Disk Volume) 
RPINV Main driver for the Initialize new task volume 
RP INV 1 Routines used to support the initialize volume 
process 

RPINV2 Same as RPINVl 

RPINV3 Routines used to initialize disc process 
RPINV4 Utility routines for the Initialize new volume 
process 

RPIOR Utility routines for the IV, UV, and INV SVC 
handlers 

RPIV Handles the main portion of Installation of a 
disc volume 

RPPRCK Routine that checks for memory protection 
vl olat ions 

RPPEVT Processor for SVC >4F (Post Event) 

RPPSVC Processors for SVC 04 , 1 0 , 1 B , 24 , 2B , 2C , 33 
(miscellaneous) (program-support SVCs) 

RPRCDA Data base for SVC 4C (Return Code Processor) 

RPRCP Processor for SVC 4C (Return Code Processor ) 

RPRETR Processor for SVC 3F (Retrieve System Data ) 

RPROOT Decoder for SVC requests 

RPSDAT Module that Includes the system static buffer 
and a table (RPSTAB) built during sysgen, 
showing characteristics and processors for DNOS 
SVCs 

RPSGCK Routine that checks for mapping violations 
RPUDAT Includes the table RPUTAB built during sysgen, 
showing characteristics and processors for 
user-defined SVCs 

RPUTIL Utility routines and data areas for the IV, UV , 
and INV SVC handlers 

RPVOL Processors for SVC 20,34 (Install Disk and 
Unload Disk) 

RPWAIT Processor for SVC 42 (Walt for Event) 

RPWTIO Processors for SVC 01,36 (Walt for I/O) 

Other modules that process SVC requests are found In the 
subsystems for I/O, name management, job management, program 
management, and segment management* Short descriptions of the 
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routines that process SVCs can be found In the relevant subsystem 
descriptions . 


6.3 MAPPING STRUCTURE 

Due to the large number of SVC processors, one map file segment 
cannot contain all of them. Therefore, two arrangements of map 
file 0 are set up during sysgen. One arrangement has these three 
segments mapped in: system root, requester JCA, scheduler /fl rst 
SVC segment. The other arrangement has these three segments 
mapped in; system root, requester JCA, second set of SVC 
processors. A flag in the RPSTAB entry shows which of the map 
arrangements is needed for processing a particular SVC. Before 
passing control to the processor, the decoding routine makes sure 
that the correct map file Is being used. When the processor 
terminates, the return routines ensure that the map file with the 
scheduler segment Is restored. 


6.4 DATA STRUCTURES USED FOR SVC PROCESSING 

The primary structure used by the SVC decoding routine Is the SVC 
definition table built during sysgen. This table, RPSTAB, is 
created to define completely all DNOS SVCs Included In the 
current system configuration. Users who supply any of their own 
SVCs must build a similar table, RPUTAB, to describe those SVCs. 
The RPSTAB table is located in a module named RPSDAT; the user 
defined table Is placed into a file named . S$SGU$ . USERSVC.RPUDAT . 

Each DNOS-suppor t ed SVC code has a two-word description field In 
RPSTAB. For codes that are undefined In a particular 
configuration, both words are zero. Figure 6-1 shows the two- 
word description format. 
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BYTE 0 - FLAG BYTE 

BIT 0 - 0= Do not check alignment; l=check alignment 

1- 0= Use registers to buffer; l=use table area 

2- 0= Use first SVC segment of processors; 

1= Use second SVC segment of processors 

3, A - Reserved 

5-7 - Length to buffer, If going to registers; 
otherwise 0 
BYTE 1 - LENGTH BYTE 

>00 If buffering In table area 

Length of whole call block If buffering In registers 
BYTES 2,3 - ADDRESS WORD 

Address of request definition block (RDB) If 
buffering In STA 

Address of processor If buffering In registers 
Figure 6-1 SVC Entry Form In RPSTAB 


SVC processors that execute quickly and require little 
Information from the SVC call block have the required Information 
buffered In registers. Upon entry to the SVC processor, the 
following registers are set: 

* RO - bytes 0,1 of call block (or zero If unused) 

* R1 - bytes 2,3 of call block (or zero If unused) 

* R2 - bytes 4,5 of call block (or zero If unused) 

* R3 - requester call block address 

* RA - requester TSB address 

* R5 - requester map file pointer In TSB 

When using a buffer In STA, a structure called the request 
definition block (RDB) Is used to tell how much and which fields 
to buffer. The RDB Is defined In the module with the memory- 
resident processor or preprocessor. If one Is used. For SVCs 
processed by tasks with no preprocessors or for SVCs that are 
configurable options of DNOS, the RDB Is defined In the RPSDAT 
module. The RDB Is labeled RDBSxx for system SVC opcode xx . A 
template for the RDB Is shown In the section on data structure 
pictures. Figure 6-2 shows examples of RDBs . 

For many of the requests buffered according to an RDB, 
Information must be returned from the processed buffered request 
to the requesting task. The structure used to govern this 
transfer Is the return Information block (RIB) built for the SVC. 
A RIB Is needed If Information In addition to the return code 
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must be passed back to the requester task. The RIB for system 
opcode XX Is RIBSxx and Is shown In detail In the section on data 
structure pictures. Figure 6~2 shows an example of an RIB. 


RDBS14 EQU $ 

DATA >0800 
DATA OVYQUE 
DATA 0 
DATA >0007 
BYTE >07 
BYTE 0 
DATA 0 


LOAD OVERLAY RDB 
USE DYNAMIC BUFFER IN STA 
OVERLAY QUEUE SERVER HEAD 
NO RIB NEEDED 
MAX BUFFER SIZE 
BASIC BLOCK LENGTH 
ACCOUNTING FACTOR 
RESERVED 


RDBS48 EQU $ JOB MANAGER RDB 

DATA >1800 PREPROCESSOR, DYNAMIC BUFFER 

DATA JMPREP ADDRESS OF PREPROCESSOR 

DATA RIBS48 RIB ADDRESS 

DATA >0010 MAX BUFFER NEEDED IS 16 BYTES 

BYTE >10 BUFFER 16 BYTES 

BYTE 0 ACCOUNTING FACTOR 

DATA 0 RESERVED 


RIBS48 EQU $ 

DATA 0 NO POST PROCESSOR NEEDED 

BYTE 0 START UNBUFFERING AT BYTE 0 

BYTE >10 UNBUFFER 16 BYTES 

DATA 0 END OF RIB 


Figure 6-2 Examples of RDB and RIB Structures 

The job management SVC Is one example of an SVC that must be 
rebuffered for certain sub-opcodes. The flags defined In the RDB 
for expansion govern that rebufferlng. This technique Is used 
because request blocks for sub-opcodes within the SVC opcode vary 
In size. The preprocessor of the SVC must make a call to RPBUF 
with a revised RDB to rebuffer special cases. 

SVC processing uses several data structures In addition to the 
RDB, RIB, and RPSDAT. Among these are the queue headers for the 
queue server SVC processing tasks. The queue headers are 
described In the section on nucleus functions. The SVC decoder 
uses the queue header pointer In the RDB to queue a buffered 
request to a queue server. 

SVC processing uses TSBs of the requesting tasks to access map 
file Information and to return completed requests. It uses JSBs 
to return completed requests If the TSBs are not available. 
Other structures are used by particular SVC processors but not by 
the decoder or buffering routines. 
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6.5 DETAILS OF SVC PROCESSING 

SVC processing begins In the routine RPROOT. This routine 
accesses tables to locate the appropriate processor and to 
determine buffering details. The routine RPBUF Is used to copy 
(buffer) the SVC request Into a temporary work area. The routine 
RPDQUE Is used to return the finished request to the task Issuing 
the SVC. A set of miscellaneous routines Is used throughout 
processing . 


6.5.1 Decoding Routine (RPROOT). 

When an SVC Is executed, the hardware transfers control via the 
Interrupt processing routines to the SVC decoding routine RPROOT, 
RPROOT first checks for a special SVC ( XOP 15,15) used by the SCI 
Debugger. If this special call was Issued, a flag Is set In the 
requesting task's TSB. 

A check Is then made for the Initiate Event SVC. If that SVC Is 
specified. It Is now processed In RPROOT. The SVC being 
Initiated Is checked to ensure that It Is a legal opcode and can 
be Initiated. (In the current version of DNOS, only I/O and 
semaphore operations can be Initiated.) If no errors occur, the 
Initiated SVC Is processed like any other request. 

At this point I/O and Segment Manager SVCs are checked for 
alignment and then routed directly to their preprocessors. This 
Is done to speed up the processing of those SVCs. 

RPROOT then examines the RPSTAB entry for the requested SVC. The 
first check verifies that the opcode Is defined In this 
configuration. If there Is no RPSTAB entry and no RPUTAB entry, 
error code >F0 Is returned, SVC processing terminates, and 
control returns to the requester task. 

If the SVC Is defined, the next check Is for alignment. If the 
RPSTAB or RPUTAB entry shows that the request must be aligned on 
a word boundary, the address of the request Is checked. If It Is 
not legal, error code >F1 Is returned, and SVC processing 
terminates . 

The RPSTAB entry for the requested operation Is checked to see 
whether buffering occurs In registers or In STA. If the request 
Is to be buffered In registers, RPROOT performs the following: 

1. Checks the call block for mapping and protection 
violations 

2. Transfers the required amount of Information from the 
requester call block to registers RO , R1 , and R2 

3. Ensures that the correct map file Is In use 
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4. Transfers control to the processor. When the processor 
completes Its work, it transfers control back to the 
requester task 


If the RPSTAB entry for the SVC shows that the SVC is to be 
buffered into STA, RPROOT performs the following: 

1. Accesses the RDB 

2. Checks the call block for mapping and protection 
violations 

3. Calls the buffering routine RPBUF to transfer 

Information from the requester call block to STA 
according to the RDB, creating a BRB (Buffered Request 
Block) 

4. Checks whether the request is to be queued to a queue 
header for a task or sent on to a processor in memory 

a. If the request is to be queued, RPROOT queues the 
buffered block to the queue header and suspends 
the requester task 

b. If the request is to be sent to a processor, 

RPROOT transfers control to the processor, which 
either returns to the requester or queues the 
buffered request to a task 

After RPROOT transfers control to an SVC processor, that 
processor may return control to the scheduler by branching to 
NFSRTN or NFTRTN. It may also return to RPROOT in case an error 
occurs in the processing logic. The return points are as 
f ollows : 

* RPRTNE - an error completion. RPROOT must check whether 
this was an initiated event and return only the error 
byte to the requester task. 

* RPRTNF - a task error in the requester task. RPROOT 

must check whether this was an initiated event and 
terminate the requester task with the task error passed 
from the SVC processor. If the SVC processor Itself 
encounters a logic error, RPROOT terminates the 

requester task with task error >04 to show an SVC 
processor error. ' 
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6.5.2 SVC Buffering Routine (RPBUF). 

RPBUF Is a general request buffering routine called by RPROOT and 
by several SVC preprocessors that have received a partially 
buffered block from RPROOT. RPBUF uses the RDB provided by the 
caller to determine how to buffer the Information. 

RPBUF first checks the RDB flags to see If this buffering Is to 
use the single system static buffer (provided as part of the 

RPSTAB module) or a dynamic buffer. If a dynamic buffer Is to be 

used, a flag Is checked to see whether the buffer comes from STA 
or from the requester JCA. A dynamic buffer of the size 
specified In the RDBMAX field of the RDB Is then allocated via 
the nucleus routine NFGTA. 

If RPROOT called for this buffering, RPBUF now sets up the 
buffered request by first building the buffered request overhead 
(BRO). The BRO Is shown In the section of data structure 

pictures. It Includes a pointer to the requester TSB and JSB, 
the address of the call block In the requester task, a set of 
flags, and several fields filled during SVC processing. 

After the BRO Is completed, RPBUF Includes as much of the call 
block as Indicated In the RDBBAS field of the RDB, RPBUF then 
checks to see If expansions to this basic block are to be 

Included. If so, the next several words of the RDB Indicate 
where to buffer the Information (table area or JCA), how much to 
buffer, and at which offset Into the buffered Information to 
place the new Information. 

If the buffering request Is for revision of a partially buffered 
block, RPBUF copies the BRO and the basic request block from the 
partially buffered block to the newly acquired block. The old 
block of memory Is released via the nucleus function NFRTA, and 
expansions are treated like those In buffering for RPROOT. 


6.5.3 Dequeuing and Unbufferlng Routine (RPDQUE). 

When a task Is to be scheduled for execution, the scheduler 
examines the TSB to see If any SVC requests are to be unbuffered 
to the requester task. If so, RPDQUE Is called to remove all 
queued SVC requests. RPDQUE works with each queued request, 
returning Information from the buffered request block to the 
requester task. It passes back the return code byte and then 
uses an RIB to pass back any other Information, If the RIB Is 
defined. RPDQUE returns the number of bytes specified In RIBLEN 
from the offset RIBOFF In the BRB to the offset RIBOFF In the 
requester call block. Several sets of paired specifications may 
be present, terminated by pair of zeros. When these pairs are 
completed, a postprocessor Is called. If one Is specified In the 
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RIBPRO field. When unbuffering is complete, RPDQUE releases the 
buffer via the nucleus routine NFRTA and returns to its caller. 

A Walt for Event SVC requires special handling by RPDQUE, which 
checks the requester task TSB to see which event flags have 
completed. The flags being tested in the Wait for Event block 
are then matched against those in the TSB to generate a correct 
reply in the requester task area. 


6.5.4 Other Request Processor Support Routines. 

RPMAP2 

This routine is part of the DNOS root. It is used by RPROOT 
to access a processor in the second SVC map file. RPMAP2 
adjusts global pointer CURMAP , loads the second map file, 
and transfers control to the processor routine. If the 
processor returns to RPROOT, it passes back through RPMAP2, 
restoring the original map file. 

RPPRCK 

This routine checks the memory-protection attributes of a 
portion of memory. It first examines the protection bit in 
the status word of the task. If protection is enabled, 
RPPRCK then checks to see if the map • register limit 
Indicates write protection. If so, an error is returned. 
To allow unbufferlng of SVC request results, write 
protection must not be enabled; thus, the error causes the 
task to terminate. 

RPSGCK 

The requester call block must be mapped in by a single base 
and limit register pair to simplify processing. RPSGCK 
verifies this condition. Given any address and length, 
RPSGCK uses the relevant map file to ensure that the block 
addressed is correctly mapped. If not, an error is 
returned, which may cause the task to terminate. 


6.5.5 DNOS SVCs and Processors. 

Table 6-2 shows the processors for each of the system-defined SVC 
opcodes for DNOS. In some cases, a preprocessor is shown, since 
that module is the one accessed from RPROOT; it may in turn call 
one of several processors. Some small processors that perform 
related functions have been collected into a single module; the 
listing shows both the module name and the processor name for 
these processors. 
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Table 6-2 SVC Processors and Modules 


NOTATION: 


MEANING 


A 

I 


(Not Supported) 
(pre) 

P 


(P) 

S 


(S) 

( task ) 
[ nn ] 


Alignment on word boundary required 

May be Initiated with SVC 41 

This SVC code Is Intentionally omitted. 

This Is a preprocessor 

Software privileged task required 

Some of the set require software privilege 

System task required 

Some of the set require a system task 

This processor runs as a task 

Name of module containing processor 


Processor/Preprocessor 


SVC // 

Name 

Notes 

[Module 

If Different] 

00 

I/O Operations A, 

i,(p) 

lOPREP 

( pre ) 

01 

Walt for I/O 

A 

RPWTOl 

[RPWTIO] 

02 

Time Delay 

A 

RPTDLY 

[ RPGSVC] 

03 

Get Date and Time 

A 

RPGDT 

[RPGSVC] 

04 

End of Task 


RPENDT 

[RPPSVC] 

05 

(Not Supported) 




06 

Suspend Task 


RPUNCW 

[RPGSVC] 

07 

Activate Suspended Task 


RPAST 

[RPGSVC] 

08 

(Not Supported) 




09 

Extend Time Slice 


RPETS 

[RPGSVC] 

OA 

Convert Binary to Decimal 


RPCBDA 

[ RPCONV] 

OB 

Convert Decimal to Binary 


RPCDAB 

[ RPCONV] 

OC 

Convert Binary to Hexadecimal 


RPCBHA 

[RPCONV] 

OD 

Convert Hexadecimal to Binary 


RPCHAB 

[RPCONV] 

OE 

Activate Time-Delayed Task 


RPATDL 

[ RPGSVC] 

OF 

Abort I/O Request by LUNO 


lOABRT 


10 

Get Common Data Address 


PMGRCM 


11 

Change Task Priority 


RPCTP 

[RPGSVC] 

12 

Get Memory 

A 

PMGRMM 


13 

Release Memory 

A 

PMGRMM 


14 

Load Overlay 

A 

PMOVYL 

( task ) 

15 

(Not Supported ) 




16 

(Not Supported) 




17 

Get Task Bid Parameters 

A 

RPGTBP 

[RPGSVC] 

18 

(Not Supported) 




19 

(Not Supported) 




lA 

(Not Supported) 
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Table 6-2 SVC Processors and Modules (Continued) 


SVC # 

Name 

Notes 

[Module 

if Dlf f erent ] 

IB 

Return Common Data Address 


PMGRCM 


1 C 

Put Data 

A 

PMGDAT 


ID 

Get Data 

A 

PMGDAT 


IE 

(Not Supported) 




IF 

Scheduled Bid Task 

A 

RPXSBT 

[RPPSVC] 

20 

Install Disk Volume 

A,P 

RPVOL 

( task ) 

21 

System Log Queue Request 

A 

LG SVC 


22 

Disk Management 

A,S 

DMTASK 

( task ) 

23 

(Not Supported) 




24 

Suspend for Queue Input 

S 

RPQSUS 

[RPPSVC] 

25 

Install Task 

A,P 

PMPINS 

( task ) 

26 

Install Procedur e / Segment 

A,P 

PMPINS 

( task ) 

27 

Install Overlay 

A,P 

PMPINS 

( task ) 

28 

Delete Task 

A,P 

PMPDEL 

( task ) 

29 

Delete Procedure/ Segment 

A,P 

PMPDEL 

( task ) 

2A 

Delete Overlay 

A,P 

PMPDEL 

( task ) 

2B 

Bid Task 

A 

RPXTSK 

[RPPSVC] 

2C 

Read/Write TSB 

A,P 

PMRWTB 


2D 

Read/Write Task 

A,P 

PMRWTK 

( task ) 

2E 

Self Identification 

A 

RPGSID 

[ RPGSVC] 

2F 

Get End Action Status 

A 

RPGEAS 

[RPGSVC] 

30 

(Not Supported) 




31 

Map Program Name to ID 

A 

PMPMAP 

( task ) 

32 

(Not Supported) 




33 

Kill Task 

A 

RPKILT 

[ RPPSVC] 

34 

Unload Disk Volume 

A,P 

RPVOL 

( task ) 

35 

Poll Status of Task 


RPPTS 

[RPGSVC] 

36 

Walt for Multiple I/O 


RPWT36 

[RPWTIO] 

37 

Assign Program File Space 

A, P 

PMPASP 

( task ) 

38 

Initialize New Disk Volume 

A,P 

RPINV 

( task ) 

39 

(Not Supported) 




3A 

(Not Supported) 




3B 

Set Date and Time 

A 

RPIDT 

[RPGSVC] 

3C 

(Not Supported) 




3D 

Semaphore Operations 

A, I 

PMSEMA 


3E 

Reset End Action Status 


RPREA 

[RPGSVC] 

3F 

Retrieve System Data 

A 

RPRETR 


40 

Segment Management 

A,(S) 

SMPREP 

( pre ) 

41 

Initiate Event 

A 

RPROOT 


42 

Walt for Event 

A 

RPWAIT 


43 

Name Management 

A 

NMPREP 

( pre ) 

44 

Reserved 




45 

Get Encrypted Value 

A 

SECRYP 


46 

Get Decrypted Value 

A 

SECRYP 


47 

Log Accounting Entry 

A 

PMACCT 


48 

Job Management 

A 

JMPREP 

( pre ) 
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SVC # 


Table 6-2 SVC Processors and Modules (Continued) 

Name Notes [Module If Different] 


49 Get Accounting Info from TSB 
4A Modify BTA or JCA Size 

4B Halt/Resume Task 

4C Return Code Processor 
4D (Not Supported) 

4E Comm I/O 

4F Post Event 

50 DNOS Performance Functions 

80+ User-defined SVCs 


A PMACCT 
A,P PMSBUF (task) 
A,P PMHALT 
A RPRCP (task) 


A RPPEVT 


6.6 USER-WRITTEN SVC PROCESSORS 

The standard set of SVCs uses operation codes that range from >0 
through >7F. The user may Implement SVCs using codes from >80 
through >FF. One or more codes may be specified, using any codes 
within the user-defined range. The user must design the SVC 
block, build an RDB to describe buffering, build an RIB If 
Information Is to be unbuffered, and set up a module of 
Information with the IDT name RPUDAT. During sysgen, the user 
supplies a file name for the module containing RPUDAT object and 
ensures that object modules for the SVC processor(s) are In the 
directory . S$SGU$ . USERSVC of the data disk. 


6.6.1 User SVC Table. 

The user specifies the RDB and RIB Information, as well as a set 
of general Information about all SVCs being defined. In a module 
of tables that contains the following: 

* An IDT name of RPUDAT 

* DEF statements for RPUMAX and RPUTAB 

* REF statements for each SVC processor entry point 

* A byte named RPUMAX with a value of the largest user- 
defined SVC code 

* A table named RPUTAB with a two-word entry for each SVC 
code In the range >80 through RPUMAX 

* An RDB for each user-defined SVC code 
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* An RIB for each user-defined SVC that must return 
Information to the caller 

The entries In the table RPUTAB consist of two words each. The 
first word is the value >E000 and the second word Is the address 
of the RDB for the SVC code being defined. The first entry in 
the table is for SVC code >80. Each successive entry is for the 
next sequential SVC code. If a particular code Is not defined In 
the system being generated, the entry In RPUTAB must consist of 
two words of zero. Figure 6-3 Includes the format of RPUTAB when 
the user Is defining several SVCs. 

An RDB for a user-defined SVC Includes the address of the SVC 
processor, flags showing how to copy the call block for 
processing, and the address of an RIB used to return information 
to the calling task. Table 6-3 shows the format of an RDB. 

Table 6-3 Request Definition Block (RDB) Format 

Field Size Contents 


Word Flags, >1000 for user-defined SVCs 

Word Address of the SVC processor 

Word Address of the RIB for this SVC 

(zero If no RIB Is defined) 

Word Size of the call block In bytes 

Byte Number of bytes of call block to 

be copied by the operating system 
Byte Zero 

Word Zero 

Figure 6-3 shows several RDB definitions for user-defined SVCs. 

An RIB is used by the operating system to return data from the 
system copy of the call block to the task that issued the SVC. 
If only the error byte of the call block must be returned, no RIB 
Is needed. If any other Information Is to be returned, an RIB 
must be specified In the RPUDAT module. Table 6-4 shows the 
format of an RIB for a user-defined SVC. The pair of byte fields 
may be repeated If information Is to be returned from several 
noncontiguous areas In the call block. 
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Table 6-4 Return Information Block (RIB) Format 
Field Size Contents 


Word Zero 

Byte Offset In the call block from which the 

return of data should begin 
Byte Number of bytes to return 

Word Zero 


The RPUDAT module must be assembled and Its object module 
pathname must be supplied during sysgen In response to the 
question about the user SVC table. Figure 6-3 shows a source 
module for defining two user SVCs, using SVC opcodes >80 and >82. 
Assume that there Is some legitimate reason to omit opcode >81. 
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* 

* THIS MODULE HAS THE DATA TABLES TO ENABLE PROCESSING OF 

* USER-DEFINED SVCS. RPUTAB IS THE TABLE OF RDB AND PROCESSOR 

* ADDRESSES FOR THE SVCS. THE SET OF RDB DEFINITIONS FOLLOWS, 

* AND RIB DEFINITIONS ARE INCLUDED FOR RELEVANT CASES. IN 


* ADDITION, 

RPUMAX 

IS DEFINED TO BE THE MAXIMUM USER-DEFINED 

* SVC 1 

4e 

CODE. 




IDT 

'RPUDAT 

/ 


DEF 

RPUMAX 

, RPUTAB lI^BELS TO ACCESS USER DATA 


REF 

SVC080 

,SVC082 LABELS OF ENTRY POINTS 

RPUTAB 

DATA 

>E000 

SVC80 - FINp CPU TIME 


DATA 

RDBU80 

i 


DATA 

0 

SKIP SVC81 


DATA 

0 



DATA 

>E000 

SVC82 - SPECIAL ADD 


DATA 

RDBU82 


RPUMAX 

A 

BYTE 

>82 

MAXIMUM USER-DEFINED CODE 

RDBU80 

DATA 

>1000 

FLAGS 


DATA 

SVC080 

PROCESSOR 


DATA 

RIBU80 

RETURN INFORMATION BLOCK 


DATA 

6 

MAXIMUM CALL BLOCK SIZE 


BYTE 

2 

COPY ONLY TWO BYTES 


BYTE 

0 

RESERVED 


DATA 

0 

RESERVED 

RDBU82 

DATA 

>1000 

FLAGS 


DATA 

SVC082 

PROCESSOR 


DATA 

RIBU82 

RETURN INFORMATION BLOCK 


DATA 

16 

MAXIMUM CALL BLOCK SIZE 


BYTE 

16 

COPY ALL 


BYTE 

0 

RESERVED 


DATA 

0 

RESERVED 

RIBU80 

DATA 

0 

RESERVED 


BYTE 

2,4 

START AT OFFSET 2, RETURN 4 BYTES 


DATA 

0 

RESERVED 

RIBU82 

DATA 

0 

RESERVED 


BYTE 

2,6 

START AT OFFSET 2, RETURN 6 BYTES 


BYTE 

12,4 

AND AT OFFSET 12, RETURN 4 BYTES 


DATA 

0 



END 




Figure 6-3 Format of RPUDAT Module 
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6.6.2 Processors for User-Written SVCs. 

The SVC processor must define (DEF) its own entry point. It 
needs to use SPUSH 1 on entry to save R1 and SPOP 1 to return to 
the OS. The processor runs as part of the operating system 
kernel, making use of an operating system workspace. Upon entry 
to the processor, the following registers are set; 

* R1 - Points to the system copy of the requesting call 
block 

* R4 - Points to the requester TSB 

* R5 - Points to the requester saved map file 

* RIO - Points to an Internal operating system stack 

* R13 - The requesting task workspace pointer (WP) 

* R14 - The requesting task program counter (PC) 

* R15 - The requesting task status register (ST) 

The SVC processor must not alter registers 13, 14, and 15. 

Register 10 should be used only for pushing and popping items on 
the stack. 

Register 1 points to the system copy of the requester's call 
block. The processor usually gathers all of the Information It 
needs from this copy. The processor alters the copied call block 
to pass Information back to the requesting task; the second byte 
of the call block should always be used for returning a status 
code. If necessary, the processor can also access the requester 
task area to get or return data by using long distance 
Instructions with register 5 as the map file pointer. 

The call block as received by the processor has several words of 
overhead as detailed In the buffered request overhead (BRO) 
template. This overhead Includes the requester's TSB address, 
JSB address, call block address, and several other pieces of 
Information. Each of these is accessible using negative offsets 
from the buffered call block pointer In register 1. 

When the processor finishes Its work. It must return to the 
operating system by Issuing the Instruction SPOP 1. The 
operating system returns Information as specified In the RIB for 
the SVC performed. Control is then passed back to the task that 
f'ssued the SVC. The DNOS Systems Programmer's Guide includes an 
example of a user-written SVC processor. 


SVC Processing 


6-18 


2270512-9701 



DNOS System Design Document 


SECTION 7 

SEGMENT MANAGEMENT 


7.1 OVERVIEW 

The segment management subsystem enables tasks to dynamically 
change the segment set mapped by the task. Segment management 
also enables a task to guarantee accessibility to a segment until 
it is no longer needed. Finally, segment management enables a 
task to write segments to disk if their attributes allow this 
function . 

Segment management also provides the operating system with 
mechanisms to manipulate data structures even when they are not 
contained in the same address space. Since DNOS Is a job- 
oriented operating system, system data structures whose scopes 
are contained within a job are located in separate segments. 
Thus, the operating system Is able to service job-level requests 
by mapping only the job-level system data structures. 

Segment management enables the file management subsystem to 
manage file buffers. By treating file buffers as segments, file 
management Is able to access any buffer, whether In memory or on 
disk. 


7.2 ARCHITECTURE OF SEGMENT MANAGEMENT 

The Segment Manager Is Implemented as three distinct levels of 
support. The first level contains routines for mapping the 
various table areas (JCAs and special table areas), finding 
Segment Status Blocks (SSB) for specific segments, creating and 
deleting SSBs and Segment Group Blocks (SGB), and causing 
segments to be loaded Into memory. These routines reside In the 
system root and are described in the section on nucleus 
f unc t 1 ons . 

The second level of segment management consists of SVC 
processors. These processors reside In the second SVC processor 
segment of map file 0. This level consists of an SVC 
preprocessor and several SVC processors. These processors enable 
user and system tasks to dynamically change the address spaces of 
their tasks. 
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The third level of segment management Is task-level support that 
enables the Segment Manager to read a program file directory 
entry for a segment. This support is needed when a Change 
Segment SVC is executed on a program file segment whose SSB is 
not in memory. The program file directory Is read to get the 
segment attributes, length, load address. Image record number, 
and attached procedure IDs (task segment). The task loader 
contains this support. A special Interface Is used between the 
task loader and the segment management SVC processors to perform 
the segment change after the directory Is read. 


7.3 SEGMENT MANAGEMENT DATA STRUCTURES 

Program files are used to support segment management. A program 
segment entry is located In the procedure section of the program 
file, thus limiting the total number of procedures and program 
segments In a program file to 255. The Install Program Segment 
SVC builds a segment entry. The format Is shown as the program 
file directory Index entry (PFI) In the section on data structure 
details. 

The SGB Is the In-memory anchor for a set of segments. The SGB 
resides In the segment management table area. The FCB points to 
the SGB for a file. If all segments of a group cannot be 
contained In the same table area, an overflow SGB Is created in a 
different table area and the SGB points to It. 

Each segment group consists of one or more segments. Each 
segment Is described by an SSB, which Is allocated In the segment 
management table area. Special table area SSB's are In STA. An 
SSB Is created by Segment Manager when a task requests a segment 
that does not currently exist. 

The overhead beet (OVB) is used to contain Information about a 
segment when it is In memory. The OVB Is located in the beet (32 
bytes) preceding the segment. 

The reserved segment table (RST) contains a list of segments 
reserved by a job. The job Information table (JIT) contains a 
pointer to the RST chain, which resides In the JCA. The RST Is 
built when the first Reserve Segment SVC Is done or when the 
current RST overflows. The RST Is deleted when It contains no 
more segment entries or when the job terminates (after releasing 
all of the segments). The format of the RST Is shown In the 
section on data structure pictures. 

A Set Exclusive Use operation creates an Owned Segment Entry 
(OSE) which points to the owned segment. The SSB points to an 
Segment Owner Block (SOB) which points back to the TSB of the 
task that has exclusive use of It. A Load Segment operation 
creates a Load Segment Entry (LSE) which points to the segment to 
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be loaded, OSEs and LSEs are chained off the TSB In the JCA, 
SOBs are allocated In the segment management table area. 

The segment management SVC block Is shown In the section on data 
structure pictures as the SMR structure. 


7.4 SEGMENT MANAGEMENT ROUTINES 

Segment management SVC processing begins In the preprocessor 
routine SMPREP. Depending on which subopcode Is specified, 
control then Is transferred to the appropriate subopcode 
processor . 


7.4.1 SVC Preprocessor (SMPREP). 

SMPREP receives control from the SVC decoder, RPROOT, with the 
pointer to the SVC call block In the task as Input, SMPREP 
verifies that the following conditions are met: 

* All of the call block Is within the task, 

* The subopcode Is within range. 

* If the operation Is a Change or Create Segment, the I/O 
count and the Initiate count for the task are zero, 
unless the task Is software privileged. 


NOTE 

The OS does not provide general support for 
proper completion of I/O when the call block 
or buffer Is mapped out of the task. When 
DNOS unbuffers the data of an IPC read-type 
operation. It does not use the task map file, 
so mapping out IPC read or master read 
buffers Is supported. 


* If a LUNO Is specified. It Is assigned to a file of a 
valid type and In certain cases. Is open. 

SMPREP uses a pointer in the Logical Device Table (LDT) for the 
specified LUNO to determine the File Descriptor Packet (FDP) that 
contains the File- Management Table and File Control Block 
(FMT,FCB) pair. The FMT,FCB addresses are saved in the segment 
management SVC block. If the memory-based segment group Is 
specified, an FMT,FCB address of zero is used. The FMT,FCB pair 
Is used to Identify the segment group In which the requested 
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segment resides. If the operation Is not change or create 
segment, the SMT,SSB pair for the specified segment is obtained. 
If It cannot be found, an error Is returned. Figure 7-1 shows 
the overall flow of control to and from SMPREP. 

XOP I REQUESTER \ 


I 

V 

+ + 

I RPROOT I 

+ + 

I 

V 

H — 

I SMPREP I 

+ + 

I (BL) 

V 

+ + 

I SVC I 
I PROCESSORS I 


I 

V 

See SVC Processing Description 
for Interface to return to user. 

Figure 7-1 Flow of Control In Segment Manager 


7.4.2 Change Segment Processor (SMCHGS). 

The Change Segment operation enables a task to change the segment 
set that comprises Its logical address space. The caller 
specifies either the LUNO for the file In which the segment 
resides or a flag to signify a memory-based segment. An ID 
(Installed or run-time) uniquely Identifies the new segment. The 
segment to be mapped out of the task Is Identified by a run-time 
ID or a map position number. 

The Change Segment processor first decides whether the caller Is 
adding, removing, or changing a segment. If the caller Is 
removing a segment, the last segment of the task is unmapped 
unless it Is a task segment. (This removal constitutes an 
error.) The routine SMRMVE is called to decrement the count of 
tasks that currently require the segment to be In memory (the 


SMLOAD-Load a Segment 

SMUNLD-Unl oad a Segment 

SMEXCU-Set Exclusive Use of a Segment 

SMREXC-Reset Exclusive Use of a Segment 

SMCHGS-Change Segment 

SMCRES-Crea t e Segment 

SMRS VE-Reserve Segment 

SMRLSE-Release a Reserved Segment 

SMCHKS-Check Segment Status 

SMFWRS-For ced Write Segment 

SMJRLS-Job Manager Release Segment 

SMMDFY- Se t /Rese t Modified and Releasable 

SMBIAS-Bias Segment Address Within Task 
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task-in-memory count ) . When this count goes to zero, the segment 
can be swapped or released from memory; therefore, SMRMVE Is 
responsible for either caching or releasing the segment. (Refer 
to the program management section for more details.) 

Add Segment and Change Segment processing are essentially the 
same except that during an add there Is no old segment to be 
removed from the task. The routine SMSRCH Is called to search 
for the requested new segment. If it Is found, SMSRCH verifies 
that It may be used by the requesting task. SMSRCH first calls 
SMFSID to see If the segment Is defined. SMFSID uses the FDP and 
ID to uniquely Identify the segment. If the segment Is found, 
the SSB address Is returned. SMSRCH then validates the segment 
attributes for the task. If a non-task segment Is share 
protected, SMCHUC is called to verify that It Is used only by the 
requesting task before SMCHGS Is allowed to map it. If a segment 
Is owned but not by this task, mapping Is not allowed. If the 
segment Is repllcatable and In use, SMSRCH duplicates the SSB. 
If SMFSID does not find the segment defined In memory, SMSRCH 
calls SMBLDS to build an SSB. If the segment is a file 
management buffer or Is memory-based, the SSB can be defined 
completely. However, If the segment Is a program file segment, 
the program file directory on disk must be read to obtain the 
segment Information. Thus, SMBLDS will place program file 
segments In the Initial load state to be processed by the task 
loader. 

Control Is received in SMCHGS with the new SSB address. If the 
new segment Is an initial load segment, control Is passed 
Immediately to the routine SMEXIT. Otherwise, certain conditions 
are checked before the segment change Is allowed. The task must 
fit Into user memory with the new segment, and the task must not 
map more than 64K bytes. Also, If any segment other than the 
last one In the task Is being changed, the new segment must be 
the same size as the old segment. An exception to this rule Is 
made for system tasks, which may change In different-sized 
segments; however, the segments' logical starting addresses do 
not change. If these conditions are met, the old segment Is 
removed from the task address space. SMRMVE disposes of It 
accordingly (not required when adding a segment). SMEXIT Is then 
called to map the new segment. 

The routine SMEXIT Is responsible for Incrementing the use count 
In the SSB, updating the WCS bit In the status register, building 
the limit register for the new segment, and updating the 
protection bits In the limit register. SMEXIT decides whether 
the new segment Is In memory. If not, the calling task Is 
deactivated and suspended while waiting for memory. If the new 
segment Is in memory, Its task-ln-memory count Is Incremented, 
the map base value Is calculated, and the calling task is placed 
Into execution with the new segment In its address space. 
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When an Initial load segment Is processed, SMEXIT suspends the 
task on the WOM list. This places the task loader Into execution 
and determines that an Initial load segment Is being requested 
(TSBSBN Is nonzero). The task loader then tests the SSBs to see 
If the task Is In the Initial load state. If so the program file 
directory entry for the segment Is read and the SSB fields are 
Initialized. Now that a segment SSB with the specified ID exists 
In memory, the task loader calls SMCHGS via an Interface routine, 
PMSMIR. SMCHGS processes the Change Segment as usual except that 
control Is returned to the task loader from SMEXIT (Instead of 
suspending the calling task or placing It Into execution). The 
task loader then loads the task as usual. Figure 7-2 shows the 
flow of control through the Change Segment processor. 


+ + 

I SMCHGS I 

+ + 

(BL) 

+ 

V 

I SMSRCH I 

+ + 

(BL) 

+ 

V I 

+ + 1+ + 

I SMFSID I I I SMBLDS | 

+ + 1+ + 

V 

— — — — — — 

I SMCHUC I 
+ + 


■+ 

V 


■+ 

V 


I SMRMVE 

— — — — — — — ■ 


(B) 

V 


1 SMEXIT 

+ 

I 

(B) 

I NFTRTN 
+ 


•+ 

I 


•+ +- 

I I 

■+ +■ 


-+ 

(B) 


NFSRTN 


Figure 7-2 Flow of Control In Change Segment 


Figure 7-3 shows the flow of control If an Initial load segment 
Is being accessed. 
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When relative record segments are created, the segment length Is 
the physical record size of the file (obtained from the FCB), 
The length and attributes for memory-based segments are defined 
In the call block. Default attributes are readable, nonsystem, 
disk resident, nonrepl 1 cat able , non-WCS, reusable, and 
noncopyable, though the user may set or reset the execute-protect 
and share-protect attributes through the call block. The write- 
protect and updatable attributes are set based on the file 
protection flags. 

The Create Segment processor first decides whether the request Is 
to add an empty segment or to change one. Much of the same 
validation Is required here as In Change Segment to ensure that 
the new segment can be mapped by the calling task. If the 
specified conditions are met, SMBLDS Is called to build the SSB 
for the empty segment. An empty segment flag is set In the SSB 
to Inform the task loader that the segment does not reside on 
disk. If a segment Is not being added, SMRMVE Is called to 
dispose of the old segment. SMEXIT Is called to finish 
processing before returning control to the calling task. The 
task is suspended by SMEXIT since the empty segment Is not In 
memory at this time. 

Special processing Is required by Create Segment for relative 
record segments. Before a new SSB Is built, a check is made to 
see If a segment with the same ID already exists In memory. If 
so', an error is returned. Figure 7-4 shows the flow of control 
through the Create Segment processor. 
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7.4.4 Reserve Segment Processor (SMRSVE). 

The Reserve Segment operation enables a task to maintain access 
to a nonupdat able segment when needed, even though the segment is 
not in any task's address space. Since segments which are not 
memory-resident may be released from memory when they are no 
longer in use, this operation is needed to retain access to these 
segments. The segment is reserved at the job level until a 
Release Reserved Segment operation is executed or the job 
terminates. All segments reserved by tasks within a job are 
contained in the RST to which the JIT points. Segments are 
removed from the RST whenever a Release Reserved Segment 
operation is done. When the job terminates and the RST Is not 
empty, the job management subsystem is responsible for releasing 
the remaining segments. Reserved segments are swapped if their 
memory is needed. The SSB for the reserved segment remains in 
memory as long as the segment is reserved. 

SMRSVE searches the RST chain for a free entry to contain this 
segment's run-time ID. If no free entries exist, a new RST is 
built. The reserve count in the SSB is incremented. Control is 
then returned to the calling task via the Request Processing 
subsystem. 


7.4.5 Release Reserved Segment Processor (SMRLSE). 

The Release Reserved Segment operation is used to release a 
segment that has previously been reserved within the job. The 
RST Includes an entry for the segment if it was reserved in the 
job. The processor returns an error if an entry is not found; in 
effect, a job cannot release segments it has not reserved. 

SMRLSE first decides if the requested segment was reserved by the 
job. If so, the entry is deleted from the RST. If the RST is 
empty, it is delinked from the RST chain and deleted. The SMT , 
SSB pair is used to find the segment that is being released. The 
reserve count is decremented. If the segment is no longer In use 
or reserved, the segment is left cached or is deleted from 
memory. SMDSSB does the following processing. If the segment is 
in memory and is reusable, the segment remains cached in memory 
(unless the releasable flag is set in the SSB, in which case the 
segment is deleted). If the segment is in memory but is not 
reusable, the segment is queued for deleting by the task loader, 
and the SSB is deleted. If the segment is not in memory, the 
swap table entry for the segment is deleted along with the SSB. 
Control then returns to the calling task via the request 
processing subsystem. 
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7.4.6 Check Segment Status Processor (SMCHKS). 

The Check Segment Status processor returns Information about a 
certain segment. Such Information Includes the segment run-time 
and Installed IDs, length, attributes, whether the segment Is a 
task and whether the segment Is memory-based. If the segment Is 
mapped by the task, the logical address of the segment Is 
returned. The segment need not be mapped or reserved by the task 
requesting the status. 

If the segment Is mapped by the task, the status Information Is 
returned along with the logical address. If the segment Is not 
found In the task, the segment group Is searched. If the 
specified ID is found, the status information for the segment Is 
returned . 


7.4.7 Forced Write Segment Processor (SMFWRS). 

The Forced Write Segment processor writes a segment to Its home 
file position (If updatable and modified). The segment Is 
represented by an SMT and SSB. The task requesting the write Is 
suspended until completion of the write. The disk I/O Is 
accomplished by a dedicated queue server of the write queue, 
PMWRIT. 

If the segment does not exist, an error Is returned. If the 
segment exists, a check Is made to determine If It Is updateable. 
If not, an error Is returned. If It Is updateable. Is In memory, 
and Is modified, the write will occur. The OVB for the segment 
Is queued to the write queue. The calling task Is then suspended 
until completion of the write. 

PMWRIT Is activated whenever an entry Is placed on the write 
queue. PMWRIT calls the file management routine FMIO to write 
the segment to Its home file. It determines whether the segment 
is a program file or data file segment. If It Is a program file 
segment, the home file record number Is contained In the SSB word 
SSBREC. For a data file segment, this record number Is contained 
In the Installed ID field of the SSB. After FMIO Is called to 
perform the disk I/O, SMDSSB Is called. Finally, if a task is 
suspended for the write (that Is, the OVB points to a forced 
write call block through the OVBBRB field), the task Is placed 
back Into execution via NFEOBR. Figure 7-5 Is a diagram of the 
flow of control through the Forced Write processor and task. 
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7.4.8 Release Job Segments Processor (SMJRLS). 

This operation is used by job management to release reserved 
segments in a specified job when the Job Manager is terminating 
that job. This operation may be executed only by a system task 
(specifically Job Manager). 

SMJRLS is called with the SMT,SSB address and the JSB of the 
terminating job. The JCA of the terminating job is mapped in for 
the segment to be released. SMRLSE is called to process the 
Release Segment operation as usual. SMRLSE then returns control 
to SMJRLS, which returns control to the caller via the request 
processing subsystem. Figure 7-6 shows the flow of control 
through the Release Job Segments processor. 
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Figure 7-6 Flow of Control in Release Job Segments 


7.4.9 Set/Reset Modified and Releasable (SMMDFY). 

The Set/Reset Modified and Releasable operation is used to mark a 
segment of a task as releasable or nonr eleasable and to mark an 
updatable segment as modified or not modified. The default 
conditions for segments are nonreleasable and not modified. 

The SSB of the segment is located, and the flags for the 
releasable and modified states are set according to the SVC 
request . 


7.4.10 Bias Segment Address Within Task (SMBIAS). 

The Bias Segment Address Within Task operation is used to 
position segment two or three of a task at a new logical address. 
This is used primarily by the System Configuration Utility. This 
subopcode (>08) is not available to users. 


7.4.11 Set Exclusive Use of a Segment (SMEXCU). 

The Set Exclusive Use of a Segment operation is used to extend 
the share-protection attribute to segments not currently mapped 
in by a task. A segment which has had exclusive use set is said 
to be an owned segment. Other users who try to map in the owned 
segment will get a shared segment violation error (unless it is 
repl 1 cat able , in which case a replicated copy will be mapped). 
The set operation also has the functionality of a reserve segment 
operation. That is, even if an owned segment has use and reserve 
counts of zero, the segment will not be deallocated. 
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If the operation Is to succeed, the following conditions must be 
met ; 

* The segment must not currently be owned by either the 
task Issuing the SVC or another task. 

* The segment must not be In use by any task but the 
Issuing task. 

SMEXCU calls SMCHUC (Segment Management Check Use Count) to 
perform this function. Exclusive use of special table areas 
(SMTs, FMTs, PBMs) Is not allowed. Once It Is determined that 
the preceding conditions are met, a segment owner block (SOB) Is 
linked to the SSB, Indicating which task owns this segment. An 
owned segment entry (OSE) Is linked to the Issuing task's TSB, 
Indicating which segments the task owns. 


7.4.12 Reset Exclusive Use of a Segment (SMREXC). 

The Reset Exclusive Use of a Segment operation relinquishes a 
task's ownership of a segment. The operation will succeed only 
If the segment Is currently owned by the task Issuing the SVC. 
The SOB Is delinked from the SSB and Its memory released. The 
OSE Is removed from the list of owned segments linked to the TSB 
and Its memory released. If the segment Is not In use or 
reserved. It Is deleted. 


7.4.13 Load a Segment (SMLOAD). 

The Load Segment operation assures the user that the specified 
segment will be In memory while the task that Issued the SVC Is 
executing. The segment will not be mapped Into the task address 
space. A segment may be loaded by more than one task regardless 
of Its attributes. When loading a segment, a load segment entry 
(LSE) Is built and attached to the loading task's TSB. 

SMLOAD Is not only an SVC processor but Is accessed with a BL 
Interface by nucleus routines. It executes In Map 0. 

7.4.14 Unload a Segment (SMUNLD). 

The Unload Segment operation detaches the segment from the task 
so the segment does not need to be In memory when the task Is In 
memory. An error Is returned If the segment was not loaded by 
the task. The LSE Is delinked from the TSB. If the reserve, use 
and exclusive use counts are zero, the segment may be cached or 
deleted. 

SMUNLD Is not only an SVC processor but Is accessed with a BL 
Interface by nucleus routines. It executes In Map 0. 
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7.5 SEGMENT MANAGEMENT TABLE AREA 

Segment Manager maintains Its Internal data structures In special 
table areas that are separate from the STA. These blocks contain 
SSBs and SGBs. During sysgen, a variable number (one or more) of 
these areas are defined to fit Into the second segment of the 
system mapping scheme (replaces JCA segment). 

Sysgen creates an SSB In the STA for each segment management 
table area. These SSBs are used by the Segment Manager to access 
each table area. The tables reside In the memory-based segment 
group; thus, a memory-based SGB resides In the STA. Each table 
area has the standard memory management overhead along with a 
pointer to the first SGB In the table and Information required to 
generate run-tlrae IDs for SSBs. The Get and Release table area 
routines (NFGTA and NFRTA, respectively) are used to allocate 
memory In the special table areas. 

Whenever a new segment group Is being created. Segment Manager 
decides which table area has the most unused memory and allocates 
the segment group Into this area. Segment Manager will attempt 
to allocate all segments of a group within the same table area. 
If this Is not possible, an overflow SGB Is created In a 
different table area. The overflow SGB contains the same 
Information as the SGB (which points to the overflow SGB). Thus, 
Segment Manager can search all segments of a group by searching 
the segments that reside In the table, then search the segments 
that reside In a table to which the overflow SGB points. Figure 
7-7 Is a general diagram of the Segment Manager table scheme 
(given two table areas). 
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SECTION 8 
JOB MANAGEMENT 


8.1 JOB CONSTRUCT 

A job is the fundamental work unit to which DNOS logical 
resources are allocated. These resources Include files, devices, 
IPC channels, and environments of names. 

The goals of the job construct In DNOS are the following: 

* To provide a structure for the information about a group 
of related tasks (for example, resources allocated, 
security level, and accounting Information) 

* To provide the capability of divorcing tasks from an 
active physical terminal 

* To provide a vehicle for easy migration of applications 
between DNOS configurations by isolating a set of tasks 
from all others In a system 

A job consists of one or more tasks, a set of job-local 
variables, a set of resources, a set of job-local LUNOs , and a 
job ID. The operating system constitutes a job In that It owns 
files, devices, and channels and consists of a group of 
cooperating tasks. 

A job has an associated priority. This priority is used for 
scheduling various system services. Such as disk events and 
positioning requests Into the spooler queue. 

Management of resource allocation by jobs In DNOS provides a 
level of Isolation between different jobs. Once resources have 
been allocated to a job, the execution of the job can be 
independent of the existence of other jobs. Hence, jobs also 
provide a migration vehicle from a single- to a multiple- 
application environment. 


8.2 OVERVIEW OF JOB MANAGEMENT 

The Job Manager assigns and manages job Identifiers, limits the 
number of jobs in the system, and provides system access 
security. To support these functions, the Job Manager processes 
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the following SVCs: 

* Create Job 

* Halt Job 

* Resume Job 

* Modify Job Priority 

* Map Job Name 

* Get Job Information 

* Kill Job 

A task requests creation of a job via the Create Job operation of 
the Job Management SVC (>48), The Job Manager performs security 
checks to validate the Integrity of the request and generates a 
unique job ID. The job Is created and Is set Into execution If 
It will not exceed the system job limit. If this Is a batch job, 
It must not exceed the background job limit also. If either 
limit will be exceeded, the job Is placed on a queue, waiting for 
some other job to terminate. Security on the Halt, Resume, Kill, 
Get Job Information, and Modify Job Priority operations Is 
provided so that only a user with the same user ID or a part of 
the system job may perform these operations. A job determines 
Its own job ID through the use of the Self Identification SVC 
(>2E). Status Information on jobs Is obtained via system 
ut 111 ties . 


8.3 ARCHITECTURE OF JOB MANAGEMENT 

Job Manager Is a system task that executes In the system job. It 
Is coded In Pascal with minimal run-time support and Is a disk- 
resident queue server. It has an assembly language 
Initialization routine, which contains the stack space for the 
Pascal routines. Like other system tasks written In Pascal, Job 
Manager uses routines In DSC.PASASM to call nucleus functions. 

Job Manager serves a singly linked list of entries. The Job 
Manager logical address space consists of the system root, a JCA 
segment, and task code. Any task requesting a Job Management SVC 
Is suspended until the request has completed. 


8.4 JOB MANAGEMENT DATA STRUCTURES 

Among the data structures used by Job Manager are several 
structures particular to segment management and nucleus 
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functions. These Include SSBs, BRBs , and TSBs. The job-related 
structures primarily used by Job Manager Include the JCA, JSB, 
and JIT. 

The JCA contains all data structures local to a given job. The 
JCA Is allocated from free memory and can be swapped when all the 
tasks in a job are swapped out of memory. The JCA may be 
expanded, as necessary, up to the maximum size specified during 
sy sgen . 

The JSB carries all global data about the job. Including the 
address of the JCA, job ID, job name, and priority. It is 
allocated from the STA. 

The job management SVC request block is the JMR . 

The JIT contains the list headers for structures In the JCA and 
is allocated as the first portion of the JCA. 

Details of each of these structures are shown In the section on 
data structure pictures. 


8.5 JOB STATES 


The state of a job Is maintained In its JSB and changes only In 
response to SVCs Initiated by the user. The following states are 
pos slble : 

* Creating - A job Is In this state only during the 

execution of the SVC that creates that job, or while 

waiting for the active or background job count to drop 
below this limit. 

* Halted - A job Is In this state when halted by a Halt 

Job SVC. Only queue server tasks In this job can 

continue to execute. Any other tasks that attempt to 
become active while the job is In this state are 
suspended . 

* Executable - A job In the executable state can have Its 
tasks scheduled for memory and CPU. 

* Terminating - A job is placed in this state when It Is 

killed or after its last task has terminated. At this 

point, no more tasks may be bid In the job, and Job 
Manager begins releasing all resources and data 
structures within the job. 
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* JCA being expanded - A job is placed in this state while 
its job communication area is being expanded due to job 
requirements for more data structures than the current 
JCA can accommodate. 

In addition to these job states. Job Manager can also cause a 
task to enter the job suspended state. This state is used when 
halting a job. 


8.6 DETAILS OF JOB MANAGER ROUTINES 

Job management SVC processing begins in the routine JMPREP. 
Depending on which operation is requested, control then is 
transferred to the appropriate operation processor. 


8.6.1 Job Manager Preprocessor (JMPREP). 

JMPREP is a small assembly language routine that resides in the 
scheduler segment of map file 0. It causes the BRBs for certain 
sub-opcodes to be rebuffered to Include more information than 
originally buffered by the SVC decoder. To rebuffer," JMPREP 
builds an RDB showing what to rebuffer and calls the request 
processor buffering routine, RPBUF, to perform the data movement. 
JMPREP then queues the BRB to the Job Manager queue for 
processing and returns to the scheduler to suspend the requester 
t ask . 


8.6.2 Job Manager Request Processing Task (JMMAIN). 

JMMAIN is the main module for Job Manager. It acquires and 
releases segments as necessary and Initializes local variables. 
It also provides all functions common to the SVC processors, such 
as retrieving the BRB and getting the proper JCA. At the end of 
SVC processing, it will start any jobs on the waiting queue, 
provided that the job limit and batch job limit are not exceeded. 


8.6.3 Create Job Processor (JMC$). 

JMC$ must map in the caller's JCA area and retrieve some of the 
values stored in the JIT. When the new user ID flag is not set 
in the flag word of the BRB, then the user ID, passcode, account 
number, and privilege level are copied out of the caller's JCA 
into the BRB for use at a later time. 
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Once the call block Is buffered, a JSB Is built in the STA. A 
unique job ID is generated and is used to identify the job while 
it remains in the operating system. This ID is placed in the JSB 
and is returned to the caller in the BRB. The job priority is 
checked to see if it is in the range of 0 through 31. If not, 
the request is returned with an error status. Otherwise, the JSB 
state is set to indicate that it is being created. 

Next, Job Manager obtains memory for the JCA area by executing a 
Create Segment SVC. This segment is placed in the second map 
segment of Job Manager, replacing the system JCA segment. The 
size of this JCA area is specified in the call block as 1, 2, or 
3. The code 1 is for the smallest JCA size; the code 3 is the 
maximum JCA size. The logon default is the medium JCA size. All 
of the memory management overhead is initialized in the JCA, and 
segment manager SSB addresses for the JCA are stored in the JSB. 
The queue headers for the job level queue servers are 
Initialized, and the JCA segment is reserved. 

The station ID of the job being bid is next verified to be sure 
that the station specified exists and is available for use. If 
an Illegal station is specified, the job creation request is 
denied and an error is returned. If the station is legal, 
creation continues, with Job Manager assigning a job-local LUNO 
to DUMY. 

The requester may specify a logical name and synonym segment in 
the SVC block. (The function of this segment is detailed in the 
section on I/O.) When this field is zero, no action is taken. 
Otherwise, the segment is checked to see if it is a memory-based 
segment. When it is located, the segment manager SSB addresses 
are stored in the JIT, and the segment is Included in the job 
reserved segment list. If the segment is not found or is not 
memory based, the request to bid the job is aborted and an error 
is returned to the user. 

After the synonym segment is processed, the user ID and passcode 
are verified. When the new user ID flag is set, all information 
must be verified before it can be used. The user ID and passcode 
are kept on disk in a predefined system file. A search is made 
for this user ID in this file. Once the ID is found, the 
passcode specified is encrypted and compared against the 
encrypted passcode on disk. Any error in this process aborts job 
creation. If the file .S$ACCVAL exists, the account ID is 
verified against the file entries. If a match is not found, the 
job is aborted. If the file .S$ACCVAL does not exist, no 
checking is done. 

The final step in creating a job is to bid the initial task. 
First, the JSB is linked into the system JSB list. Then the 
parameters for the task are built into a Bid Task SVC, which is 
Issued from Job Manager. (Note that because Job Manager is 
issuing the SVC, the specified program file LUNO must be global 
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so that It appears In the new job's LUNO hierarchy.) Any error 
returned from the Bid Task SVC Is placed In the BRB and aborts 
the Create Job SVC. 

The new task Is Initially bid In a halted state. After the bid 
has been completed, a job Initialization entry Is placed on the 
accounting queue and the job Is put on a wait queue. 

Whenever the Create Job SVC has been aborted, the JCA and JSB 
must be returned to free memory. The BRB for the call Is sent 
back to the caller, along with the error. A temporary BRB Is 
created to Indicate job termination and Is placed on the Job 
Manager queue. This entry Is processed by JMD$, releasing all 
the resources the job had and returning them to the system. 


8.6.4 Halt Job Processor (JMHALT). 

JMHALT calls the verify routine, JMVRFY, to verify that the 
specified job ID exists and that the requesting job has the 
authority to perform the halt. The job state Is then checked to 
ensure that the job Is active. If it Is not active, an error Is 
returned. Otherwise, the job state Is changed to halted. The 
TSB list for the job Is then searched for all active tasks. 
During this search, the scheduler must be Inhibited to prevent 
any change In the list. When active tasks are found. If they are 
not queue server tasks they are delinked from the job active list 
and the task state Is changed to Indicate that the job Is 
suspended. After all of the active tasks are found, the 
scheduler Is enabled and the BRB is returned to the caller with a 
successful completion code. 

While the job Is In a halted state, only queue server tasks In 
the job can be made active. If any other task tries to become 
active, the nucleus function NFPACT places the task In the job 
suspended state. 


8.6.5 Resume Job Processor (JMRESU). 

After JMRESU calls JMVRFY, If no error was found. It checks the 
job state to see If It Is halted. If it Is not halted, an error 
is returned to the caller. If the job is halted, the job state 
Is changed to executable, and the TSB list Is searched for tasks 
In the job suspended state. When such a task Is found. Job 
Manager calls NFPACT to place the task back on the active list. 
The scheduler must be Inhibited during the TSB search so that the 
TSB list Is not altered. After the search, a successful 
completion code Is placed In the BRB, and the BRB Is returned to 
the requester. 
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8.6.6 Modify Job Priority Processor (JMPRIO). 

JMPRIO calls JMVRFY and. If no error was found. It checks that 
the caller Is the system operator. If not, an error Is returned. 
The new job priority Is checked to see If It Is within the valid 
priority range. If not, the request Is aborted. Otherwise, the 
tasks within the job are updated to reflect the new priority. 
Job Manager calls a nucleus routine to obtain the new task 
priorities. During this time, the scheduler must be Inhibited. 
After all of the priorities are modified. Job Manager delinks the 
first active task In the job and then relinks It. This Inserts 
the JSB In the right position for the scheduling queue. The new 
priorities take effect when Job Manager completes Its SVC 
requests. Job Manager then enables the scheduler and returns the 
BRB with a successful completion code. 


8.6.7 Map Job Name Processor (JMMAP). 

The Map Job Name processor searches the JSB list for the job name 
specified In the BRB block. It returns the job ID of the first 
job that It finds with the same user ID as the calling task. 
Jobs In terminating state are not considered. An error Is 
returned If no matching job name Is found under that user ID, or 
If the job name Is duplicated. In the latter case, the job ID of 
the first matching job Is returned. The user ID and job names of 
each job are kept In the JSB (which Is memory resident) to avoid 
excessive swapping during this operation. 


8.6.8 Get Job Information Processor (JMINFO). 

The Get Job Information processor returns Information about the 
job Identified by the job ID In the requestor call block. If an 
ID of zero Is specified. Information about the caller's job Is 
returned. JMVRFY Is called, and If no error Is returned, this 
processor returns the job name, priority, user ID, account ID, 
privilege level, and the run ID of the calling task. 


8.6.9 Kill Job Processor (JMKILL). 

The Kill Job processor terminates jobs within the system. JMKILL 
verifies that the user has access to the specified job and that 
the job exists. The job state Is then checked to see If the job 
Is already In a terminating state. If It Is, an error Is 
returned In the BRB to Indicate this condition. When the job Is 
In the create state. It must be deleted from the waltlng-to- 
execute job queue. At this point, the job state Is changed to 
terminating so that no new tasks are bid In this job. The 
scheduler Is then Inhibited during the kill process for each 
task. 
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Job Manager kills each task by calling the nucleus function 
NFTERM, The TSB contains a flag to Indicate whether end action 
Is allowed on a kill request. If It Is not set, the task may 
take end action but will not be able to reset Its own end action 
bit. A time-out value for end action prevents the task from 
executing Indefinitely. Job Manager returns a successful 
completion code In the BRB when all of the tasks have been 
processed through NFTERM. 

Job Manager suspends (awaiting queue Input) at this point to 
allow all of the tasks to terminate. The termination processor, 
PMTERM, places an entry on the Job Manager queue to notify Job 
Manager that the last task has terminated. When the entry 
arrives, control Is given to JMD$ to complete the job termination 
process . 


8.6.10 Job Clean-Up Routine (JMD$). 

JMD$ Is a support routine that can be activated only by an 
aborted Create Job SVC or by PMTERM. The call Is made when the 
last task of a job has terminated. JMD$ Is responsible for 
releasing any attached resources and all memory blocks associated 
with the job. 

JMD$ may be called during the create process to clean up an 
aborted Create Job SVC. JMD$ first determines If the JCA area 
for the job exists. Job manager releases the JSB If the JCA was 
not created. 

The first set of operations required for the JCA Is to release 
any job-local LUNOs still assigned. The I/O sub-opcode to 
Release LUNO In Another Job Is used for this purpose. The entire 
list of LUNOs Is searched, and a call block for each of these 
LUNOs is created and passed on to the I/O Utility (lOU). 

After all of the LUNOs have been released, all resources that 
have been attached by the job are released via calls to lOU for 
each resource found. The resource list is searched, and for each 
entry found a Detach by Number SVC sub-opcode is Issued. 

The next structure to be deleted Is the reserved segment list. 
For each reserved segment, a call Is made to the Segment Manager 
to cancel the reserve. This Includes the reserve on the JCA 
segment. The JCA segment Is mapped into Job Manager during this 
release process and Is not released from memory until Job Manager 
changes Its second map segment. All other segments, such as 
logical name and synonym segments, are released and become 
eligible for deletion If no other job has reserved them. All 
clean-up of memory-based segments is accomplished by Segment 
Manager when Job Manager releases the reserved segments. The 
table memory for the reserved blocks Is also released from the 
JCA by Segment Manager during this process. 
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At this point In the clean-up process, the JCA should not have 
any dynamic memory allocations In It. If no other job has 
reserved this JCA segment before the job was put In the 
terminated state, this JCA Is deleted as soon as Job Manager 
releases It from Its address space. 

The last step In JMD$ Is to release the JSB from the STA. The 
JSB Is deleted from the JSB list, and the memory Is returned. A 
job termination entry Is placed on the accounting queue and the 
active job count Is decremented. 


8.6.11 Verify Job ID Routine (JMVRFY). 

The verify routine Is used by JMKILL, JMINFO, JMRESU, JMHALT, and 
JMPRIO to determine If the caller Is allowed to execute the SVC 
In question. This routine searches the JSB chain to find the 
appropriate job ID. Jobs In terminating state are not 
considered. If the job ID Is not found, an error Is placed In 
the BRB and the request Is aborted. Otherwise, JMVRFY checks to 
see If the operation Is being executed on the system job. Any 
attempt to perform one of these SVCs on the system job receives 
an error. The last check made Is to verify that the requesting 
task has the privilege to perform the SVC. Valid requesters are 
the system operator, tasks whose jobs have a flag set to bypass 
ownership tests, and tasks whose jobs have the same user ID. All 
other requesters receive errors. On successful completion, 
JMVRFY returns to the calling routine with the JCA of the 
requested job mapped Into the second map file segment of Job 
Manager and with the JSB address of the job requested. 


8.7 IMPLICATIONS OF JOB BOUNDARIES 

In theory, a task running In a job Is not aware of any other job. 
It may Interact with the system job by Issuing an SVC or It may 
Interact with another job by using a global IPC channel, but It 
theoretically Is Independent of and unaware of any other job. In 
reality. It may be necessary for two tasks In different jobs to 
communicate with each other. 

There are two major mechanisms supported by DNOS for cross-job 
communication: global IPC channels, and event SVCs. The major 
difficulty with global channels Is that the owner task must be 
the first task to assign a LUNO to the channel, but, aside from 
that, they have all the power that the various channel 
configurations provide. Events provide a more limited 
capability, being mainly a synchronization feature. Any task 
which knows another task's job ID and task run-time ID can Issue 
a Post-Event SVC which causes a specified event to complete for 
the task specified by the job ID and run-time ID. The specified 
task must Issue a Walt for Event SVC for the event number of the 
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expected event. It will then be activated when the Post 
SVClslssued. 
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SECTION 9 

PROGRAM MANAGEMENT 


9.1 OVERVIEW 

Program management supports task-level requests to execute tasks, 
load overlays, and terminate tasks. Support Is also available to 
perform sy chroni zat 1 on operations, to read and write task memory 
or TSBs, to get and release user memory, and to get and release 
system common. Program management Includes processors for the 
full set of SVCs to support program files. 

Program management Is Implemented In three distinct levels. The 
first level Includes support routines that reside in the root of 
the operating system. These routines are callable by various 
program management routines and perform specific functions. The 
second level Is the set of processors for the program management 
SVCs which execute at XOP level. The third level Is the 
processors for program management SVCs that execute as queue 
serving tasks. Many program management SVCs are implemented in 
the second level only, but some require a third level (for 
example, disk I/O may be performed only at the third level). 


9.2 DATA STRUCTURES USED BY PROGRAM MANAGEMENT 

In addition to JSBs, TSBs, various segment management structures, 
and the JCA, program management uses a number of lists and queues 
to coordinate the efforts of Its components. These structures 
Include the following: 

Wa 1 t 1 ng -on-Memor y (WOM) list 

A list of JSBs anchored by the NFPTR field WOMJSB, with each 
JSB having one or more TSBs for tasks that must be loaded. 
The TSBs of each job are linked from the JITWOM anchor in 
the JIT of the JCA. The JSBs are ordered by JSB waiting 
priority as carried In the JSBWPR field. 

Loader Queue 

A linked list of OVBs, each representing a block of user 
memory to be released. The queue Is anchored at LDRQUE In 
NFQHDR. 
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Cache List 

A linked list of OVBs for segments currently In memory but 
not currently used by any active task. (These are the most 
recently used segments, and they may be used later or 
deallocated.) This list Is anchored at CHELST In NFDATA. 

Active List 

A list of JSBs for jobs with tasks ready to execute. This 
list Is anchored In the NFPTR field ACTJSB, organized by 
priority JSBAPR. The TSBs for the active tasks are linked 
from the JITACT anchor In the JCA. 

Time-ordered List (TOL) 

A list of task segments (OVBs) representing all tasks In the 
system eligible for the active list, ordered by most 
recently loaded. 

Time Delay List 

A linked list of time delay entries, anchored by the NFPTR 
list header TDLHDR. The entries reside In the STA and 
consist of task Identification Information and time delay 
values. Walt for Event SVC's are also linked on this list. 

Swap Table 

A linked list of swap table entries used to keep track of 
allocated space and segments on the swap file. Whenever a 
segment Is swapped to the swap file, a swap table entry Is 
built for that segment In the system JCA, and a pointer to 
It Is placed In the SSB. This table Is used by the segment 
swapper task to keep track of which records are allocated In 
the swap file. The anchor for this list Is ROLDIR In 
PMDATA. 


9.3 DETAILS OF PROGRAM MANAGEMENT ROUTINES 

Program management routines perform the functions of bidding a 
task, loading a task for execution, and deallocating resources 
when a task terminates. 


9.3.1 Task Bid Processor (PMTBID). 

When a Bid Task SVC (>2B) Is executed, the nucleus function 
NFTBID attempts to add the task to the active list. If NFTBID Is 
unable to bid the task, the SVC block Is placed on the task bid 
queue that places the queue server PMTBID Into execution. 

PMTBID performs the Initial setup for a task. It ensures that 
the task exists by locating the task segment In memory or by 
reading the program file directory. Then, the procedure segments 


Program Management 


9-2 


2270512-9701 



DNOS System Design Document 


(if any) are located in memory, or they are built from the 
program file directory. The map file limit registers are built 
for the task and the TSB for the task is placed on the WOM list 
so that its segments will be loaded by the task loader. 

Execution of PMTBID proceeds as follows. The routine PMGSSB is 
called to find or build an SSB for the task segment. The routine 
SMSRCH is called to search the program file segment group for the 
requested segment. If found, it is used by the task being bid 
(assuming the segment attributes allow this). If the segment is 
not found, SMBLDS is called to build an initial load SSB for the 
segment. (For details see the description of segment 
management.) When control is returned to PMGSSB and if the SSB 
returned is in the initial load state (that is, the program file 
directory has not been read for the segment), PMRDIR is called to 
read the program file directory entry for the segment. PMMPRI is 
then called to calculate the initial runtime priority. Next, 
PMTBID calls PMITSB which calls PMGSSB for the attached 
procedures, sets up the map file limit registers (Including 
protection), determines the total mapped length and memory used, 
and initializes the task status. A loaded segment entry (LSE) is 
built for the JCA of the task, so that the JCA will be loaded 
into memory when the task is loaded. PMTBID calls PMNMGR to 
Inform the name manager that a new task exists in the job, then 
links the TSB into the TSB tree and activates the task. The task 
is now ready to be loaded by the task loader. Finally, the 
calling task, if any, is killed or suspended if such action is 
requested in the SVC block. 


9.3.2 Task Loader (PMTLDR). 

PMTLDR loads tasks into memory when they are initially bid, when 
they have been swapped out of memory and are rescheduled to run, 
and when a Change Segment or Create Segment operation is done for 
a segment that is not in memory. The task loader serves the 
loader queue and the WOM list. Included in the task loader task 
are the get and release user memory routines and the task 
swapping routine. 

PMTLDR begins to execute whenever an entry is placed on the 
loader queue or WOM list. The loader queue is processed first. 
It contains a list of segments whose memory must be deallocated. 
The return user memory (PMRUM) routine is called for each 
segment . 

After processing the loader queue, PMTLDR checks the WOM list for 
a task to be loaded. If one is found, PMTLDR attempts to load 
the task into memory. PMTLDR first checks to see if the task is 
doing a Change Segment operation which requires initialization of 
an SSB. If so, PMRDIR and PMSMIR is called to allow the segment 
manager to complete its processing. PMTLDR calls the routine 
PMALSG to allocate memory for the task's JCA and later for each 
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segment of the task. The JCA must be in memory before the task 
can be loaded, since the JCA contains the TSB. PMALSG first 
checks to see If the segment Is already In memory. If so, the 
segment Is removed from the cache list If the task-ln-memo ry 
count Is zero. If the segment Is not in memory, the get user 
memory (PMGUM) routine Is called to allocate memory. If memory 
Is available, PMALSG increments the task-ln-memory count and 
returns the segment to PMTLDR. If memory Is not available, 
PMROLL Is called to attempt to obtain memory for the segment. 

After memory Is allocated for all of the task segments, PMLDSG Is 
called to load each segment Into memory. If the segment Is 
already In memory or is empty, the load is skipped. Otherwise, 
the segment Is loaded from Its home file or roll file. The 
record number for the segment Is computed, and the file 
management routine FMIO Is called to load the segment from disk 
into memory. After the load Is completed, the OVB Is Initialized 
and control Is returned to PMTLDR. 

After all of the task segments are loaded, the map file bias 
registers are calculated and the task segment Is placed on the 
TOL by calling NFATOL. The task Is put on the active list, and 
PMTLDR continues processing the loader queue and the WOM list. 

If Insufficient memory Is available to load a task, the task 
loader calls a swapping routine (PMROLL) to attempt to free 
memory by temporarily writing segments to the swap file. The 
swapping routine includes two phases. The first phase processes 
the cache list (segments In memory that are reusable but not 
currently In use), freeing any available memory. If the first 
phase does not yield enough memory, the second phase begins 
processing the TOL to find a task that can be deactivated and 
swapped . 

Processing the cache list Involves searching the list, last to 
first, for available segments. A segment on the cache list can 
be swapped If Its TILINE I/O count is zero. A maximum count for 
buffer segments and program file segments Is maintained to ensure 
that memory does not become too fragmented by cached segments. 
(See the roll parameters shown In the NFDATA template In the 
section on data structure pictures.) PMROLL tries to prevent the 
rolling of JCAs and. In an attempt to Improve performance, tasks 
doing file I/O and file buffer segments. 

When a swap candidate is found, it Is queued to the write queue 
to be written to Its home file, written to the swap file, or 
released, based on its attributes, use count, and whether It was 
modified. PMROLL returns a code of zero If It was able to free 
enough memory before returning. However, PMROLL might have 
queued an entry on the write queue. In which case PMROLL returns 
a code of 2 to the task loader, indicating that memory will not 
be available until I/O completes. If PMROLL finds an eligible 
segment doing file I/O, it returns a code of 4, Indicating that 
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task loader should serve the file 1/0 request first. 

If none of these conditions arises after processing the cache 
list, PMROLL processes the TOL. The TOL Is searched, last to 
first, to find the most eligible task for deactivation and 
swapping. The following are three categories of tasks on the 
TOL, listed In the order of most eligible to least eligible for 
swapping ; 

1, Tasks suspended for more than a minimum amount of time 
or suspended while waiting for coroutine activation. 

The longer the suspension, the more eligible for 

swapping , 

2, Tasks of lower priority than the task being loaded by 
the task loader. The lower the priority, the more 
eligible the tasks are for swapping, 

3, Tasks that have the same priority as the task being 
loaded by the task loader and that have executed for a 
minimum amount of time since they were last loaded. 

The longer the execution time, the more eligible the 
tasks are for swapping. 

After an eligible task entry Is found on the TOL , the task Is 
deactivated and Its segments are placed on the cache list If they 
are not being used by other active tasks. The cache list Is then 
processed again before returning to the task loader with the 
return code from the cache list processor. If no eligible 
entries are found on the TOL, a return code of 3 Is given to the 
task loader. Indicating that no memory was found to release. 

Figure 9-1 shows the flow of control through the task loader. 
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Figure 9-1 Flow of Control In Task Loader 


9.3.3 Task Termination Processor (PMTERM). 

When a task terminates by Issuing an End Task SVC or Is killed by 
another task or by the operating system, the Initial processing 
Is done by NFTERM (see the section on nucleus functions). That 
processing Includes placing an entry on the task termination 
queue, which Is served by PMTERM. PMTERM cleans up the memory 
structures associated with the task (TSB). 

If there Is no end-action and the task was a task- or job-local 
channel owner, PMTERM notifies IPC. For each LUNO on the TSBLDT 
chain PMTERM Issues an abort request. If no end-action Is 
specified, PMTERM closes the LUNO and waits for I/O to complete. 
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Then PMTERM either waits for or causes all other outstanding 
requests to complete and if end-action is specified, the task is 
activated. Otherwise, PMTERM releases all LUNOs, logs a task 
error (if necessary). Informs the name manager that a task is 
terminating, and delinks the TSB from the TSB tree. This may 
involve killing descendant tasks or activating a parent task. If 
there is only one task left in the job (file manager), it is 
killed. If there are no more tasks left, job manager is 
activated to terminate the job. 


9.4 TASK SYNCHRONIZATION 

DNOS provides synchronization on several functional levels. 
These levels correspond to the assumed commonality between the 
tasks requiring synchronization. The synchronization tools 
Involved are Interprocess communication (IPC) messages, 
semaphores, locks, and events. IPC is discussed in the section 
on 1/ 0 . 

9.4.1 Semaphores. 

Semaphores enable two tasks to exchange timing signals. A 
semaphore is Implemented as an integer variable and a queue of 
waiting tasks. The Integer variable indicates the number of 
unconsumed timing signals. If no signals are present, the 
Integer indicates the number of tasks waiting for a timing 
signal. 

Serna phore operations are provided on job-local variables via SVC 
>3D. The subopcodes in this SVC have the following meanings: 

Subopcode 0 ; SIGNAL 

The value of the semaphore specified by byte 3 of the SVC 
call block is Incremented. The oldest task queued on the 
semaphore queue is activated. 

Subopcode 1 : WAIT 

The value of the semaphore specified by byte 3 of the SVC 
call block is decremented. If the resulting semaphore value 
is negative, the task is suspended and queued to the 
specified semaphore. 

Subopcode 2 : TEST 

The value of the semaphore specified by byte 3 of the SVC 
call block is returned in bytes 4 and 5 of the SVC block. 

Subopcode 3 : INITIALIZE 

The semaphore specified by byte 3 of the SVC call block is 
initialized to the value specified in bytes 4 and 5 of the 
SVC block. If any tasks are queued waiting for this 
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semaphore, the action taken depends on the new value of the 
semaphore as follows: 

* If the new value Is greater than or equal to 0, activate 
all suspended tasks. 

* Given that n Is (new value - old value). If the new 
value Is less than 0 and n Is greater than 0, activate n 
tasks, starting with the oldest queued task. 

Subopcode 4 : MODIFY 

The semaphore specified by byte 3 Is set to the sum of Its 
old value and the two's complement (negative) value 
furnished In bytes 4 and 5 of the SVC block. If any tasks 
are queued waiting for the semaphore, the action taken 
depends on the new value of the semaphore, as described In 
the Initialize operation. The modify operation combines the 
test and Initialize operations so that correct results are 
obtained, even If other tasks are using that semaphore. 

Semaphore values are represented as signed Integers ranging from 
the negative value of -128 to a positive value of 127. A 
positive value Indicates the number of signals sent but not 
received. A negative value represents the number of receivers 
waiting for signals unless the semaphore has been negative since 
the last time It was changed In a negative direction to a 
negative value by an Initialize or modify operation. 


9.4.2 Locks . 

The synchronization tool available to tasks that share the same 
task address space Is the lock. Locks enable tasks to Implement 
mutual exclusion on critical sections of their code or data. 
Locks are represented as boolean data Items, which Indicate the 
state of the lock. 

Locks can be Implemented In assembly language by using the ABS 
and SETO Instructions on a data variable. If tasks spend 
relatively little time executing In locked regions, the following 
code will achieve the desired mutual exclusion: 


INITLK 

• 

SETO 

LOCK 

Initialize the lock 

• 

AGAIN 

ABS 

LOCK 

test the lock 


JLT 

GOTLOK 

* got the lock, use It 


SVC 

TDELAY 

* no, delay and retry 

GOTLOK 

• 

JMP 

• • 

AGAIN 

* 

• 

SETO 

LOCK 

free the lock 
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The higher-level synchronization primitives (SVC semaphores and 
IPC messages) are available to tasks at this level that do not 
meet the general assumptions about locks. 


9.4.3 Event Synchronization. 

To Improve throughput, DNOS allows the execution of some SVCs In 
parallel with the task execution. The Initiate Event SVC (>41) 
provides this concurrency. It also eliminates polling In those 
situations where polling might be used because concurrency Is 
unavailable. A set of 32 event flags Is maintained in each TSB, 
showing which of the allowed 32 events Is currently initiated or 
completed for the task. 

The Initiate Event SVC points to an SVC to be initiated. An 
event number is generated by DNOS to Identify this event. Event 
numbers range from 0 through decimal 31. In the current release 
of DNOS, I/O SVCs and semaphore SVCs can be Initiated. If the 
operating system permits the specified SVC to be Initiated, 
control is returned to the task after that request block has been 
buffered. If not, an error Is returned to the user. The user 
must exercise caution, since the operating system may return 
information to the Initiated SVC block at any time. 

The Walt for Event SVC (>42) allows a task to wait for any of a 
set of events to occur. This SVC waits until one of several 
events has completed or until the maximum wait time Is exceeded. 
The events to be waited for are specified by an event mask. The 
leftmost bit of the first word of the event mask corresponds to 
event 0. If this bit Is set In the mask, the task Is activated 
when event 0 Is completed. The event flags returned to the call 
block Indicate which (one or more) of the 32 events have 
completed. 

The Post Event SVC (>4F) permits the user to post any event In 
any task In any job but the system job. This means that any Walt 
For Event may be aborted before Its event Is completed or Its 
wait time has expired. The Post Event SVC should not be used to 
abort a wait for a valid Initiated event; It should be used to 
provide a cross-job synchronization mechanism. If task A In job 
ONE executes a Walt For Event with a large time delay without 
Initiating an event, then it will delay until either Its time 
delay expires or It Is posted, either from job ONE or from 
another job. This provides a method to deactivate and reactivate 
user-written queue server tasks, across job boundaries. To 
facilitate this operation. Issuing a Walt For Event with a 
maximum time delay of -1 (>FFFF) is special cased to cause a 
virtually Infinite maximum delay time. 
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SECTION 10 
I/O SUBSYSTEM 


10.1 OVERVIEW 

The I/O subsystem moves data between any combination of logical 
and physical I/O resources and programs (tasks) that process the 
data. The logical resources are the files located on disk or 
magnetic tape and the channels between programs. The physical 
resources are the devices attached to the computer. 

An I/O request enters the I/O system via the SVC Interface. This 
Interface provides resource-independent, resource-specific, and 
utility paths through a single SVC opcode, SVC 00. Most I/O is 
achieved via the resource-independent call because programmers 
usually want only to obtain data, process that data, and output 
the processed data without knowledge of special features of the 
I/O resource . 

However, some special-purpose programs require knowledge of the 
I/O resource. They must use specific techniques and formats to 
obtain, process, and output data. These programs use resource- 
dependent I/O. 

The utility path allows for dynamic management of resources 
without intervention from outside the computer. Actions such as 
reserving a resource, specifying access privileges, and releasing 
access are performed via the utility path. 

The general form of the I/O SVC request block ( IRB) is shown in 
the section on data structure pictures. The basic block is 12 
bytes long, while the full IRB for complex requests is 
considerably longer. 

An I/O request enters the I/O subsystem from RPROOT, the SVC 
decoder. The I/O system screens out the utility requests via the 
subopcode and passes them to the I/O Utility (lOU). The I/O 
system then finds the request routing information for those that 
are not utility requests. The routing information provides for 
checking on the operations allowed to the requester. A copy of 
the request call block is made in the STA so that the requester's 
memory space may be free for other tasks while the request is 
being processed. 

The routing Information is used to move the request to the 
correct resource handler. Channel requests are handed to the IPC 
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processor. File requests are given to the file management (FM) 
processor. Device requests are handed to the device manager. 
The device manager Is responsible for setting up the data buffer. 

The request data buffer Is moved to the buffer table area (BTA) 
if the destination resource transfers data relatively slowly. 
This copy of the request data buffer is made so that the task 
memory space may be released while the request Is being 
processed. Resources that move data quickly need not have the 
data buffer copied; they access the data directly from the 
requester task memory space. The device manager passes the 
buffered request copies to the physical device handler, the DSR, 
for processing . 

The DSR moves the data between computer memory and the physical 
device. This transfer usually occurs at the maximum rate of the 
device. During this transfer, the scheduler selects other 
programs to execute. 

When the transfer has completed, the hardware causes a device 
Interrupt to signal the DSR, Indicating that the request has 
completed. The DSR sets up conditions such that the next time 
the scheduler selects a program to execute. It finds that the 
request has finished processing. The scheduler then activates 
the requesting task. Also, any request waiting to be processed 
by that DSR Is passed to the DSR. 

When a program Is activated by the scheduler, a check Is made 
before the program Is allowed to execute to see If any buffered 
SVC requests are to be returned to the program. For I/O SVCs, 
status Information and buffered data are returned. 


10.2 DEVICE I/O DATA STRUCTURES 

Data structures used for handling device I/O are of two types. 
One set describes the devices and is built by the system 
generation utility. The other type of structure is built by the 
I/O and I/O Utility subsystems when requests are made to use 
devices. The following structures are built during system 
generat Ion ; 

* Physical device table (PDT) - Memory-resident data 

structure, one built for each device defined for the 
system. Contains Information about the device name, 

characteristics, and workspace for the device service 
routine . 

* Alternate PDT - A short version of a PDT, built for 
subdevices of a device. An example is the cassette unit 
of an ASR terminal. The DSFAID flag In the field PDTDSF 
Identifies the PDT as an alternate. The field PDTDIB 
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points to the master PDT, that is, the PDT for which 
this represents a subdevice. The byte PDTTYP is a 
binary indicator of the subdevice. There can be no more 
than 256 subdevices per master PDT. Note that these 
structures must be carefully avoided by some processors; 
power-up must bypass all alternate PDTs , for example, 
and abort processing must also avoid them. 

* Disk PDT extension (DPD) - Structure appended to the PDT 
for a disk device. Used as a work area by the device 
service routine and the Disk Manager. 

* Keyboard status block (KSB) - Structure appended to the 
PDT for a device with a keyboard. Used as a workspace 
by the device service routine when handling the 
keyboard . 

* Line printer PDT extension (LPD) - Structure appended to 
the PDT for a line printer device. Carries flags and 
pointers for use by the device service routine. 

* Magnetic tape PDT extension (MTX) - Structure appended 
to the PDT for a mag tape device. Carries flags and 
counters for use by the DSR. 

* Extension for a terminal with a keyboard (XTK) - 
Structure appended to the KSB for a device with a 
keyboard . 

* Extension for a 940 or 931 terminal - Structures 
appended to the KSB for a 940 or 931 terminal. These 
are described In the paragraph on asynchronous DSRs. 

The following structures are built when a request Is Issued to a 
device : 

* Logical device table (LDT) - Built by the I/O utility to 
carry the logical unit number to be used for requests, 
characteristics of the device, and the current 
processing state. 

* I/O request block (IRB) - Built by the I/O preprocessor 
as a buffered copy of the I/O SVC Issued by the 
requester . 

* Buffered request overhead (BRO) - Built by the request 
processing root and by the I/O subsystem to describe the 
originator of the IRB and the current state of the 
request, this is appended to the front of the IRB. 
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10.3 DEVICE I/O HANDLING 

Figure 10-1 and Figure 10-2 show the flow of control through 
device handling. Figure 10-1 Is an overall view, while Figure 
10-2 details the entrance to device processing. The figures show 
the major I/O modules Involved, as well as support routines from 
the nucleus and SVC request processing systems. 
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Figure 10-1 Overview of Device I/O Handling 


10.3.1 Details of I/O System Routines. 

When the requester task Issues an I/O SVC, control Is passed to 
the SVC decoder, RPROOT. After determining that request Is for 
the I/O system, RPROOT passes It directly to the I/O request 
preparation routine, lOPREP. 

lOPREP functions as a preprocessor that Is a uniform entrance 
Into the I/O system and prepares the I/O request for the 
destination resource. If any error Is detected by lOPREP, the 
error bit Is set In the user call block flags, and lOPREP exits 
to RPRTNE In RPROOT. RPRTNE returns the error byte to the user 
call block and checks flags for Initiated events. 
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Figure 10-2 Beginning Device Request Processing 


2270512-9701 


10-5 


I/O Subsystem 


DNOS System Design Document 


lOPREP passes the request and control to lUPREP If the request Is 
a utility request. Otherwise It builds a copy of the request In 
the STA static buffer, SYSBUF, Including buffered request 
overhead (BRO) and the entire call block. lOPREP then calls 
lOFLDT to locate the LDT. The LDT contains Information about the 
destination resource as a logical unit number (LUNO). If the 
resource pointer In the LDT Is zero, the request Is for the dummy 
device (DUMY); consequently, the request Is simply returned as 
complete via RPRTNE. 

For a device other than DUMY, the LDT Is examined to see If the 
device has been opened, that Is, some task has Issued an I/O SVC 
with the Open subopcode. If the device Is open, the LDT carries 
the TSB and JSB addresses of the task that opened It. The task 
attempting to use the resource must be the task that opened the 
LUNO. 

If the LUNO Is open to the requester task, various subopcodes In 
the I/O requests are treated differently. The Modify Access 
Privilege subopcode Is treated as an Open. Otherwise, control Is 
transferred around the open process. Read Characteristics 
subopcode requests are allowed to bypass the requirement that the 
LUNO be open. 

If the LUNO Is not open, the subopcode Is checked to see that It 
Is an Open. The open process checks for a Resource Privilege 
Block (RPB) to see If the Open Is allowed. If It Is, the LDT is 
opened and the access privileges are placed Into the LDT and RPB. 
Requests of all subopcodes are channeled through the next part of 
lOPREP, which tests again to determine If the request Is allowed 
with the current access privileges. If the request Is legal, 
control Is passed to lOCHKX for further processing. 

lOCHKX buffers the remaining portion of the request Into SYSBUF 
according to the device type specified In the LDT. The STA Is 
used since It Is available to devices and file management when 
the JCA Is not In memory. The data buffer Is not allocated or 
buffered at this time. Using more Information from the LDT, 
control transfers to the IPC processor, IPCPR2; to the file 
management processor, FMPREP; or to the device processor, lODEVR. 

lODEVR functions as a uniform I/O entrance to device resources. 
It has an alternate entry point (lODDIO) for direct device I/O of 
system tasks that must bypass checks on general requests. The 
primary entry point determines If a buffer should be allocated 
from the BTA and If data should be buffered. After these 
decisions are made, the paths from the two entry points come 
together. 

lODEVR now checks to see If the device In use Is represented by 
an alternate PDT, that Is, Is a subdevice of some master device. 
If so, the flag BRFAPI Is set In the field BR00F2 of the buffered 
request overhead of the I/O request block. The binary ID of the 
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device Is copied from the alternate PDT to the field BROAID. The 
master PDT pointer is retrieved from PDTDIB of the alternate PDT 
and now used as the PDT pointer for processing. 

The request is then Inserted on the PDT waiting queue, PDTWQ, and 
control is given to the PDT end-of-record logic routine, lOPEL. 
When control returns from lOPEL, the request is checked to see if 
it is complete in lORTN. If so, control passes to the nucleus 
return routine, NFTRTN. If the request is not complete and it is 
not an initiate mode request, the task state is set to suspended 
for I/O, and control is given to the nucleus suspend routine, 
NFSRTN. If the request is an initiate mode request, control is 
given to NFTRTN. 

lOPEL functions as a device control module outside of hardware 
Interrupts, setting up requests to devices and returning requests 
to tasks. The loop for processing begins by calling a system log 
routine, LGDEV, to log any errors stored in the PDT. Requests 
are set up for the device if the PDT saved request block address, 
PDTSRB, is zero and PDTWQ is not zero. Before any processing, 
lOPEL sets the hardware Interrupt level in the status register to 
prevent interrupts. The first request is removed from PDTWQ, the 
device map file is changed to map in the request, the data buffer 
address in the BRB is adjusted, and control is given to the 
device begin routine, lODBGN. 

When control returns from lODBGN or if PDTSRB is nonzero, the PDT 
spent request queue, PDTSRQ, is examined. If PDTSRQ is nonzero, 
a request is removed from it, and NFEOBR is called to Insert the 
request on the TSBEOR queue. This then loops back to the logging 
process. If the device is busy or there are no more waiting 
requests and no more completed requests, control returns to the 
calling routine. 

lODBGN is an Interface routine that changes the map file from the 
current state to a state in which the DSR is mapped with its data 
buffer. lODBGN must be in the first of the three segments of map 
file 0 in order to perform this function. After the new map file 
has been set up, the DSR is entered at the request entry point 
(one of several entry points). Alternate entry points in lODBGN 
correspond to some of the other entry points in the DSR. These 
alternate entry points are lODREE for system interrupt entry, 
lODABT for request abort, and lODTO for time-out, lODPDS for 
priority scheduling, and lODPU for power-up. Before giving 
control to the DSR, lODBGN saves the address of the PDT workspace 
for power failure. 
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10.3.2 I/O Processing by the DSR. 

A DSR Is the request processor for a physical resource. The 
first five Instructions beginning at relative location 0 of the 
DSR must be branch Instructions. These branch Instructions 
correspond to five alternate entry points In the DSR. A sixth 
branch Instruction must be Included If the DSR uses priority DSR 
scheduling. The branch Instructions correspond to the following 
alternate entry points. 

* Hardware Interrupt, the routine that handles Interrupts 
from the device 

* System Interrupt, the routine that handles the request 
for the system to reenter at approximately 50 
milliseconds later. 

* Power up, the routine that Initializes the device. 

* Request abort, the routine that handles the abort of a 
request that the DSR Is processing 

* Request time-out, the routine that processes the 
condition In which the device has not responded In a 
certain length of time. 

* Initial request processing. If priority DSR scheduling 
Is used then this must be a branch Instruction to the 
routine that handles Initial request processing. If 
priority DSR scheduling Is not used, then Initial 
request processing code begins here. 

* Priority DSR scheduler (optional) 

If priority DSR scheduling Is used, the Instruction following the 
Initial request processing entry point Is the routine for 
processing requests for priority DSR scheduling. Priority DSR 
scheduling Is used by DSRs which need to be reentered but do not 
want to wait the 50 milliseconds for a system Interrupt. This 
mechanism reenters the DSR after all Interrupt processing to the 
system Is complete but before the task scheduler Initiates any 
task execution. 

DSRs which use priority scheduling must link in the routine 
lOPDSQ. The DSR requests priority scheduling by Issuing a BLWP 
(3I0PDSQ Instruction. The routine lOPDSQ will queue the PDT to 
the priority scheduling queue. NFSCHD and NFTRTN check for PDTs 
on this queue and reenter the DSR at the earliest opportunity. 
This Is Intended for use only by high priority Interrupt 
processing. Using this mechanism arbitrarily may Interfere with 
other devices that use this entry point. 
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When a hardware Interrupt occurs, the interrupt vector tables 
(initialized during sysgen) are used to transfer to the 
appropriate interrupt decoder. There are four decoders provided 
with DNOS, each serving a class of devices: 

* A single device at a unique Interrupt level 

* Multiple devices at a single interrupt level 

* An expansion chassis at a single Interrupt level with 
multiple devices, each at a unique Interrupt level 
within the chassis or multiple devices sharing a unique 
Interrupt level within the chassis. 

* Single device or multiple devices on a multiplexed 
device controller 

Each Interrupt decoder goes through the following steps to 
process the Interrupt: 

1. Save the current system map file pointer (accessed via 
CURMAP) . 

2. Set CURMAP to the DSR map file pointer for the 
approprlateDSR. 

3. Load the map file using CURMAP. 

4. Enter the DSR at the hardware interrupt entry. 

5. When the DSR completes, restore CURMAP to point to the 
previous system map file. 

6. Load the map file using CURMAP. 

7. Exit via NFTRTN. 


The text of the Interrupt decoder can be found in the section on 
writing a DSR in the DNOS Systems Programmer's Guide . 

Whether handling hardware interrupts or entering the DSR at other 
points, the DSR uses the PDT for the device as a reference point. 
The section on data structure pictures Includes details on the 
PDT. 

A queue header in the PDT allows the DSR to accept multiple 
requests for the device and to call the DSR end-of-record 
routine, ENDRCD, as many times as necessary to dispose of 
completed requests. (ENDRCD is one of several routines in the 
module lONRCD.) To handle the multiple requests, the DSR must 
remove the request from PDTSRB (clearing PDTSRB) and Insert the 
request on the PDT hidden request queue, PDTHRQ. By clearing 
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PDTSRB, the DSR appears to be not busy. PDTHRQ is used as an 
internal queue anchor for the DSR; the operating system can use 
PDTHRQ to abort requests or to allow the task to wait for 
requests. 

ENDRCD is the first step in returning the request to the task. 
Not much can be done at this level because of the time spent with 
hardware interrupts masked to the interrupt level of the device. 
ENDRCD expects PDTSRB to contain the address of the request that 
has just completed. If PDTSRB is zero, ENDRCD returns to the 
DSR. If PDTSRB is nonzero, ENDRCD removes the request from 
PDTSRB, clears PDTSRB, and inserts the request at the end of 
PDTSRQ. If the PDT end -of -re cord queue (PDTERQ) is zero, the PDT 
is Inserted at the end of the list of PDTs that need end-of- 
record processing. This list is anchored by EORNKR, found in 
NFPTR, and has PDTs queued via their PDTERQ fields. The priority 
of the executing task is compared with the priority for the 
requesting task. If the request priority is higher, the global 
forced reschedule flag, RESCHD (found in NFDATA) , is set to 
preempt the running task. Control then returns to the DSR. 

Figure 10-3 shows timing, system Interrupt, hardware Interrupt, 
and end-of-record support for DSRs. The figure highlights only 
the main modules or routines. 

The task scheduler, NFSCHD, Interacts with the I/O system to 
handle system Interrupt and end-of-record functions. When a 
system time unit (50 milliseconds) has elapsed, NFSCHD calls the 
device timer routine, lODTMR. lODTMR traverses the PDT list, 
examining it for flags set to reenter a DSR and to wait for 
request time-out. When the reenter me flag is on, it is turned 
off and lODREE is called. If the PDT is busy, the time-out flag 
is on, and the PDT times out, an error code for device time-out 
is placed in the active request and lODTO is called. (lODREE and 
lODTO are alternate entry points to module lODBGN.) 

NFSCHD determines that device end-of-record processing is 
required by finding a nonzero value in the global queue anchor, 
EORNKR. When this occurs, the end-of -r eques t routine for PDTs, 
lOEOR, is called. lOEOR removes the first PDT on EORNKR and then 
calls lOPEL to process the end-of-record. lOEOR removes each PDT 
from the list until it is empty. lOEOR then returns to the 
scheduler. 
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Figure 10-3 DSR Control Paths 


10.3.3 Returning Information to the Requester. 

Figure 10-4 shows how Information is returned to the requester 
task. After a task is scheduled and prior to execution, NFTRTN 
is called. (NFTRTN is also the exit point for non s u s pend i ng SVC 
processors.) Before NFTRTN returns control to the requester 
task, the TSBEOR field of its TSB is examined for a nonzero 
value. When TSBEOR is zero, control drops through for the other 
checks. Otherwise, RPDQUE is called. 


2270512-9701 


10-11 


I/O Subsystem 



DNOS System Design Document 


NFSRTN is similar In nature to NFTRTN except that it is the exit 
point for SVCs that suspend task scheduling. Before suspending 
the task, NFTRTN examines TSBEOR for a nonzero value. When It is 
zero, control drops through and the task is suspended. 
Otherwise, RPDQUE Is called. 

RPDQUE removes the first entry from TSBEOR. RPDQUE examines the 
SVC code In the BRB, unbuffers the error code, and calls the SVC 
post processor If one exists. The post processor for I/O is 
lOPOST. When control returns from lOPOST, RPDQUE releases the 
BRB, checks for another entry on the queue and processes any. 
When no entries remain. It returns to its caller. 

lOPOST examines the subopcode to determine If It Is an I/O 
utility opcode. If so, parameter buffers are released and other 
Information is unbuffered to the task. If the request was made 
through lODDIO In lODEVR, the LDT address Is zero and requests 
are not unbuffered. Otherwise, the system flags are unbuffered. 
For relative record files, the record number Is returned to the 
task. For VDT requests, the extended user Information Is 
unbuffered. The SVC subopcode Is then used to index into a table 
to unbuffer Open, Read, and Write Information. 

For Open subopcodes, the resource type Is returned to the task. 
If an error code Is In the BRB for an Open or a Close, both the 
LDT and the RPB are closed. For a Read subopcode, the data 
buffer Is moved to the task data buffer If the buffer beet 
address In the BRO , BROBBA, Is a nonzero value. If BROBBA is 
zero, the buffer has already been moved by some other processor. 
Control then passes back to the caller, RPDQUE. 
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Figure 10-4 Returning Information to the Requester 


10.3.4 Bidding a Task from a DSR. 

DNOS provides a means to bid a task from a DSR. A two character 
sequence must be entered to Initiate the task bid. The first 
character entered Is the arming character, Attention. The second 
character entered Is used to Identify the task to be bid. For 
example, the sequence Attention ! can be used to bid SCI. In 
addition to the task bid sequences, DNOS processes the following 
character pairs as Indicated: 

Attention Attention - halt current output to screen, 
resume output 

Attention Return - abort I/O to the screen 
Attention Control-X - break - terminate current task 
Attention N - bid the network logon task 

These can be redefined or more character sequences can be defined 
by the user. For each task to bid, the user must supply a 
Command Definition Entry (CDE). The CDE Is associated with the 
type of device at which the bid can be made. During IPL, a file 
of CDE tables Is Initialized for each type of device that might 
be used for task bidding. This file is assumed to be in 
VOL . S $ CDT . XXX , where VOL Is a synonym for the disk volume being 
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used as a data disk and xxx Is the name of the generated system. 

The format of a CDE Is shown In the section on data structure 
pictures. Each CDE Includes a task ID for a logon task to be 
bid, as well as a task ID for the task to be bid by the logon 
task, flags, and parameters for the task to be bid by the logon 
task. The logon task Is either the task supplied with DNOS or 
some user-written substitute. The supplied logon task solicits 
user ID and passcode, verifies their accuracy, and bids the task 
specified In byte 3 of the CDE. (More detail on the logon task 
can be found In the section on system tasks.) 

When a keystroke defined by a CDE Is used at a terminal, the DSR 
makes several entries to system data structures. If no other 
task Is currently awaiting bid for the terminal In question, the 
PDTCHR field of the terminal PDT Is set to the character entered. 
The PDT Is linked to the global list of PDTs with pending bids, 
using the PDTBQ field as a link field. The global list Is 
anchored at BIDREQ, located In NFPTR. 

When the scheduler Is scanning lists to find an activity to 
begin. It examines the BIDREQ anchor to see If any PDT needs a 
task bid. If the anchor Is nonzero, the scheduler bids the 
system task lOTBID to serve the queue of requests. 

lOTBID takes the first request from the queue and examines It for 
validity. It first ensures that the terminal Is on-line and 
available for use. 

lOTBID then Issues a Bid Task from a DSR (>C7) subopcode of the 
I/O SVC to bid the appropriate task as defined by the CDE. Refer 
to the section on the device I/O utility (DIOU) for more details 
of that bid process. 


10.3.5 Handling Large I/O Buffers. 

The use of full-duplex operations for communication requires a 
strategy to handle many large data buffers. DNOS uses the BTA 
for large buffers rather than allocating them from STA. Figure 
10-5 shows In general how buffers are mapped with I/O processing. 

The BTA was designed to accommodate transient buffers; therefore, 
the BTA dynamically expands and contracts. During sysgen, static 
allocation limits are set. By using the Static Buffer Forced 
Roll SVC (>4A), the system can Interrogate, Increase, or decrease 
the size of the BTA. The BTA Immediately precedes available user 
memory; when Increased, the BTA causes user memory to decrease. 
This may cause forced swap of user segments that are occupying 
the requested area. SVC >4A Is detailed In the section on 
special SVC support. 
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Since the buffers are not in STA, it is possible to dynamically 
get and release BTA buffers from a DSR. Subroutines are provided 
for the DSR to get BTA (lOGBLK) or release BTA (lORBLK). To use 
lOGBLK, BL to the subroutine with workspace register 10 (RIO) 
containing the size of the buffer (bytes). On returning from the 
subroutine, workspace register 0 contains the status code for the 
request. It will be 0 if no errors occurred while getting BTA. 
RIO will contain the beet address of the allocated memory. The 
value returned in RIO should be stored in the buffered beet 
address field (BROBBA) of the BRB that will be receiving this 
buffer. The I/O system uses BROBBA as a beet address within the 
BTA to release the buffer. The first usable address relative to 
the start of the allocated BTA buffer is the value of BBAOFF 
found in the CSEG NFWORD. 

The BTA can be addressed locally by the DSR if the BTA is mapped 
in. Before mapping in the BTA, it is necessary to map out the 
buffer currently mapped in (if one is present and if it is 
different from the new one). This is accomplished by a call to 
the subroutine lOMPOT, which uses R1 as a pointer to the BRB 
containing the pointer to the buffer to be mapped out. Mapping 
in the new buffer is achieved by pointing R1 and PDTSRB to the 
desired BRB and by placing the value of BBAOFF in the IRBDBA 
field of the BRB. Then the DSR calls the subroutine lOMPIN to 
map in the BTA. This causes the IRBDBA field to contain a buffer 
address within the logical address space of the DSR. 

To release BTA, the DSR calls the subroutine lORBLK, with RIO 
containing the beet address in the BTA of the buffer to release. 
On returning from the subroutine, RO contains the status code for 
the request. RO will be zero if no error was detected. After a 
buffer in the BTA is released, BROBBA in the corresponding BRB 
must be set to zero. 

Control of buffering for a DSR is specified by information 
contained in the PDT of each device. PDTDSF contains the two 
flags, DSFBI and DSFBO. DSFBI controls the input. When it is 1, 
a buffer is allocated in the BTA for a read request. When it is 
0, a buffer is not allocated for read requests. DSFBO controls 
the output. When it is 1, a buffer is allocated in the BTA for a 
write request, and the output data is copied to the buffer from 
the task address space. When DSFBO is 0, a buffer is not 
allocated and not copied for write requests. 
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Physical memory 
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DSR Logical Memory 
Figure 10-5 Device I/O Buffering 


10.3.6 Converting a DXIO DSR for DNOS. 

Because of different Internal operating system structures and 
because of some added functions, DNOS DSRs are slightly different 
from their DXIO counterparts. A user who has his own DXIO DSR 
must change his DSR to meet DNOS standards. 

Before making any code changes, the user should study the 
relevant data structure templates used In DNOS: the PDT , IRB , 
BRO , and any other templates whose counterparts were used In the 
DXIO DSR. 

Within the DSR code Itself, the set of definitions (DBFs) and 
references (REFs) must be changed. The DNOS I/O system uses no 
DBFs supplied by the DSR. The only DBFs that must be supplied 
are those required by modules used by the user's DSR. Any other 
DBFs may be deleted. 

Several DXIO REFs are not used by the DNOS DSR. Delete the REFs 
to the subroutines SETWPS, BZYCHK, and MAPCHK. Replacements for 
these references are discussed In the following paragraphs. The 
REF for KEYFUN should be replaced by lOFCDT, and the template for 
NFPTR, DSC. TEMPLATE. COMMON. NFPTR, should be copied Into the DSR. 
The REF for BRCALL or JMCALL should be replaced by BRSTAT. REFs 
to byte and/or word constants should be deleted and replaced by 
copying In the appropriate template: 
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BYTEOO 

- 

BYTEOF 

DSC 

BYTEIO 

- 

BYTEIF 

DSC 

BYTE20 

- 

BYTE2F 

DSC 

BYTE30 

- 

BYTE3F 

DSC 

BYTE40 


BYTE4F 

DSC 

BYTE50 

- 

BYTE5F 

DSC 

BYTE60 

- 

BYTE6F 

DSC 

BYTE70 

- 

BYTE7F 

DSC 

BYTE80 

- 

BYTE8F 

DSC 

BYTE90 

- 

BYTE9F 

DSC 

BYTEAO 

- 

BYTEAF 

DSC 

BYTEBO 


BYTEBF 

DSC 

BYTECO 

- 

BYTECF 

DSC 

BYTEDO 

- 

BYTEDF 

DSC 

BYTEEO 

- 

BYTEEF 

DSC 

BYTEFO 

- 

BYTEFF 

DSC 

WDOOOl 

- 

WD8000 

DSC 


TEMPLATE. COMMON. NFEROO 
TEMPLATE. COMMON. NFER 10 
TEMPLATE. COMMON. NFER20 
TEMPLATE. COMMON. NFER30 
TEMPLATE. COMMON. NFER40 
TEMPLATE . COMMON . NFER5 0 
TEMPLATE. COMMON. NFER60 
TEMPLATE . COMMON . NFER7 0 
TEMPLATE. COMMON. NFER80 
TEMPLATE. COMMON. NFER90 
TEMPLATE. COMMON. NFERAO 
TEMPLATE . COMMON . NFERBO 
TEMPLATE. COMMON. NFERCO 
TEMPLATE. COMMON. NFERDO 
TEMPL‘ATE. COMMON. NFEREO 
TEMPLATE. COMMON. NFERFO 
TEMPLATE. common. NFWORD 


To allow for the addition of new devices at IPL and for the 
reinstallation of a new, modified, or corrected DSR without 
linking the entire system, the first addresses of the DSR must be 
the following instructions: 

B (^Hardware Interrupt entry address 
B ^System reenter me entry address 
B @Power up entry address 
B @Abort entry address 
B @Tlme“Out entry address 
B.. ^Request entry address 
B ^Priority DSR scheduler 

No data or subroutine code can precede these instructions. They 
replace the following DXIO entry points; 

DATA power-up entry address 
DATA abort entry address 

... DSR executable code for request entry 
In DXIO, the following is the first DSR executable code: 

LIMI 0 

BL 0SETWPS 

This code is not required and should be deleted for DNOS because 
the I/O system performs this function prior to entering the DSR. 

Two differences in the data structures affect code in the DSR. 
They involve the pointers in R1 and R4 of the PDT . R1 is the 
pointer to the BRB. The BRB, a concatenation of the BRO and the 
IRB, is called the UCB in DXIO. The relevant change in DNOS is 
the position to which R1 points in the BRB. In DXIO, R1 pointed 


2270512-9701 


10-17 


I/O Subsystem 



DNOS System Design Document 


to the word containing the subopcode and LUNO of the BRB . In 
DNOS, R1 points to the word containing the SVC code and error 
byte. PDTSRB points to the same place. The DSR code must be 
changed to reflect the new pointer. Any references to the DXIO 
structures named PRB and UCB must be changed to the equivalent 
references to the DNOS structure named IRB. 

R4 points to the device information block (DIB) of the PDT. (The 
device information block is the PDT and any PDT extensions.) In 
DXIO, R4 pointed to the word beyond the end of the PDT. In DNOS, 
R4 points to the first word of the PDT, the PDT link word PDTPDT. 
The DSR must be changed to reflect the new pointer location. 
References to DXIO PDT offsets must be changed to equivalent 
references to PDT template offsets. PDT labels should be used 
rather than hard-coded offset values. 

The subopcode processor, BRCALL or JMCALL, has been enhanced to 
collect information for on-line diagnostics. BRCALL can still be 
called, but note that RIO will be modified. The replacement 
subroutine call is to BRSTAT. It uses RIO as a pointer to a byte 
table that contains relative offsets into the PDT. If RIO is 
zero, it is not used as a pointer. The table is built with 
entries for each subopcode. The on-line diagnostics code counts 
types of requests for physical I/O. The entries in the byte 
table are chosen from 0, PDTRC, PDTWC, or PDTMC; these correspond 
to the null request counter, the read request counter, the write 
request counter, and the miscellaneous request counter, 
respectively. Build the diagnostics table appropriately for the 
physical device if this function is chosen. The table for BRSTAT 
is the same as for BRCALL. 

One of the subroutines for keyboard devices has a different name 
in DNOS and DXIO. The subroutine KEYFUN in DXIO is named lOFCDT 
in DNOS. lOFCDT performs the same function as KEYFUN; it also 
performs a new function, bidding a task from a DSR. (See the 
paragraphs describing bidding a task from a DSR for details.) 
All task bids in a DXIO DSR must be removed in the DNOS 
equivalent . 

lOFCDT controls processing of all bids, including the bid of SCI 
at the terminal. (SCI may be bid with or without the logon 
task.) lOFCDT also processes the hard break sequence, bidding 
the lOBREAK task. The keys used to bid SCI and the hard break 
sequence are defined in the CDE for the terminal type during IPL. 
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For devices with no KSB associated with the PDT, a bid can be 
accomplished by direct queue manipulation in place of a call to 
lOFCDT. To place the entry on the queue, first examine the byte 
field PDTCHR. If the field is nonzero, a task is waiting to be 
bid and another entry is not allowed. If PDTCHR is zero, place 
the character in the PDTCHR field. Mask interrupts to level 2 
and find the end of the queue whose anchor is BIDREQ (found in 
NFPTR) . Link the PDT to the last one on the queue using the 
field PDTBQ. Clear PDTBQ in this PDT, and enable interrupts to 
the proper level . 

The REFs for BZYCHK, SETWPS , and MAPCHK must be deleted. Replace 
the call to BZYCHK with code like the following: 

MOV @PDTSRB(R4) , R7 
JNE device busy code 
RTWP 

The function previously performed by MAPCHK is now performed by 
the I/O system prior to entering the DSR. Therefore, any code 
that references MAPCHK must be removed from the DXIO DSR for use 
with DNOS. 

In addition to the features already mentioned, some others are 
provided by the I/O system. The error code is placed into the 
BRB in power-up and abort situations. The error flag for the IRB 
i s 

set in the BRB wheneve r a nonzero value is detected in the error 
byte of the BRB. 

For processing an end-of-record for a DSR, the subroutine ENDRCD 
has been enhanced to accommodate successive calls to perform 
multiple end-of-record requests. To take advantage of this 
feature, correctly set up the pointer PDTSRB before calling 
ENDRCD. PDTSRB is the pointer to the saved request block and 
must point to the SVC and error byte of the BRB. If PDTSRB is 
zero, nothing occurs in the subroutine ENDRCD. 

For a DSR that must multiplex its input and output, a queue 
anchor for this purpose is Included in the PDT. When a DSR 
wishes to receive a second request, it must appear to the I/O 
system to be not busy. The DSR achieves this by mapping out the 
current request and clearing PDTSRB. It must then keep the first 
request available by queuing it to the hidden request queue, 
PDTHRQ, using the link word BROBRO in the BRB. In this way, the 
I/O system can find a request being aborted and flag the error 
byte with a >10 error code. During an abort, the DSR is entered 
at the abort entry and must examine PDTHRQ and abort the requests 
marked with an error code of >10. 

If the DSR multiplexes two or more requests at the same time, it 
must be careful when accessing a buffer. The buffer for only the 
request given to the DSR is mapped into the DSR address space. 
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The mapping Information for the other request remains with the 
request. Therefore, the subroutine lOMPOT must be called to map 
out a request buffer before inserting the request on the queue 
anchor PDTHRQ. R1 must point to the SVC and error code byte of 
the BRB. To map the request buffer Into the DSR address space, 
the subroutine lOMPIN must be called. R1 must point to the word 
of the BRB that contains the SVC code and error byte. Neither of 
these subroutines modifies PDTSRB. 

While It should cause no code changes, the size of the PDT In 
DNOS Is larger than that In DXIO. 

Special problems that will cause some re-deslgn of the DSR are 
the Inaccessibility of the LDT and the TSB. Although pointers 
exist in the BRO portion of the BRB, the segments containing the 

structures may be swapped out of memory. No mechanism Is 

provided to the DSR to place one of these structures Into memory 
or to map the structure Into the logical address space of the 
DSR. 

Typical problems encountered while debugging the converted DSR 
are attempts to access flags contained in the PDT registers and 

Improper use of the pointers In R1 and R4. Check the PDT flags 

used by the DSR to make certain that they exist and are 
referenced by label. 


The problems 

associated 

with R1 and 

R4 usually result 

from using 

the same method of 

reference In 

DNOS as In DXIO. 

Since the 

values in R1 

and R4 are 

pointers to 

the start of a 

structure , 

referencing 
foil ows : 

DXIO . . 

must be 

via the appropriate template 

DNOS 

fields as 

MOV 

*R1 , . . . 

MOV 

@IRBS0C(R1 ) , . . . 


MOV 

*R4 , . . . 

MOV 

@PDTSIZ( R4) , . . . 


ABS 

*R4 

ABS 

@PDTSIZ(R4) 


MOV 

. . . ,*R1 

O T 

MOV 

. . . , OIRBSOC(R1 ) 


MOV 

. . . ,*R4 

MOV 

. . . ,(aPDTSlZ(R4) 



After assembling the DSR, It must be linked with all of the 
required support subroutines. This must be done with each 
release of the operating system, not with each sysgen between 
releases. Figure 10-6 shows a typical link control stream used 
to link a DSR. 
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NOPAGE 

ERROR 

FORMAT COMPRESSED 
PROCEDURE DUMROOT 
DUMMY 

INCLUDE VOL. S$SGU$ .DUMROOT 

PHASE 0, DUMROOT 

DUMMY 

PHASE 1 jDSRname , PROG >C000 
INCLUDE VOL . DSRob ject pathname 

INCLUDE VOL. lOMGR. OBJECT. lONRCD 

(include any other support routines) 

END 

Figure 10-6 DSR Link Control Stream 

The linked object should be placed in the file 

VOL . S $ SGU$ . DSRname . VOL is a synonym for the volume name of the 
data disk being used for sysgen. 

Table 10-1 shows the modules required for the support subroutines 
and the registers altered by each of the subroutines. 

Table 10-1 Location of Support Subroutines for DSRs 

Registers 


Module Name 

Subroutine 

Changed 

VOL.IOMGR.OBJECT. lOBMGT 

lOMPIN 

RO 


lOMPOT 

RO 


lOGBLK 

R0,R10 


lORBLK 

RO 

VOL. I OMGR. OB JECT. I 0KB 

lOFCDT 

R6 


CMODE 

R5 ,R7 ,R9,R10 


PUTEBF 

— 


PUTCBF 

— 


GETC 

R9 


ASCCHK 

RIO 


ASCCK2 

RIO 

VOL.IOMGR.OBJECT.IONRCD 

BRSTAT 

R0,R10 


BRCALL 

R0,R10 


ENDRCD 

RO ,R10 

VOL . I OMGR. OB JECT . lOTILN 

GTADDR 

R9 ,R10 


XFERM 

R6 ,R9,R10 


TILERR 

R8,R9 
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10.4 TELEPRINTER TERMINAL DSR 


DNOS contains several hardcopy t e rml na 1 -dr 1 ve r DSR's: 

DSR TERMINALS FUNCTIONALITY 

DSRTPD 703,707,743,745,763,765, Local, remote KSR 
78X,820 ,825 

DSRKSR 733, 742, 782 Local, remote KSR 


This section describes details about DSRTPD as a detailed example 
of a DNOS DSR. 

Direct connection for teleprinter terminals Is supported using 
the following cable combinations: 


TERMINALSI CONTROLLERS 


1 

1 

+ 

743/745 1 

1 

1 

763/765 1 

1 

1 

78X/820 1 

TTY/EIA 

COMMIF 

/lOA 9902 PORT 
CI402 

S300 AUX 2 PORT 
CI422 

0948968-0001 

2265151-0001 

+2263351-0001 

+2200051-0001 

2262093-0001 

0946117-0001 

+2263351-0001 

+0983848-0001 

0946117-0001 

+2263351-0001 

+2200051-0001 

0946117-0001 

2303077-0001 

2230504 

1 

1 

1 

1 

703/707 1 


+2263351-0001 
+2207634-0001 
or09461 17 
+0993210-0001 

2303077-0001 

2230504 


Full-duplex modems compatible with Bell 103, 212a, 113, and Vadlc 
VA3400 series are supported, with cable 2265151-0001 from the 
TTY/EIA board, cable 946117-0001 from the COMM board, cable 
2303070-0001 from non S300 9902 ports, and cable 2532883-0001 
from S300 9902 ports. Half-duplex operation Is not available to 
these terminals through the TTY/EIA Interface module. Auto-call 
support Is provided through the Teleprinter Device Utilities of 
SCI . 

DNOS has adopted a philosophy of generating a dedicated DSR for 
each kind of I/O device supported, and of limiting access to 
Interface cards (within a given configuration) to one of these 
dedicated DSRs. DSRTPD Is to some extent a departure from this 
approach, as It allows a number of different kinds of computer 
terminals to be serviced from one DSR and one piece of interface 
hardware at different times without re -ge ne r a 1 1 on of the 
operating system. SCI functions with DSRTPD and the DNOS sysgen 
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processor comprehends the parameters and PDT structure required 
by DSRTPD. 


10.4.1 DSRTPD Structures. 

The teleprinter device family (designated KSR) is identified by 
sysgen to Include a wide variety of teleprinter terminals. The 
teleprinter device type code returned by an open operation is 
>0001 for this device family. The resource type returned on an 
assign luno for the teleprinter device family is >0902. 


10.4.2 PDT Structures. 

The TPD PDT is structured as follows: 


+ + 


1 PDT (built by SYSGEN) 

1 

1 

1 non-interrupt WS 

1 < + 

1 DNOS flags 

1 1 

1 xxxxxxxxxxxxxxxxxxxxxxxx 

1 1 

1 KSB (built by SYSGEN) 

1 

1 Interrupt WS 

1 + 

1 DNOS flags 

1 1 

1 xxxxxxxxxxxxxxxxxxxxxxxx 

1 1 

1 DIB (built by SYSGEN) 

1 1 

1 1 

1 working parameter set 

1 1 

1 scratch area 

1 1 

1 default parameter set 

1 1 

1 error counters 

1 1 

1 1 

1 KSBCBF 

1 < + 

1 input character buffer 

1 

1 (built by SYSGEN) 

1 

1 


The Device Information Block (DIB) is a data structure appended 
to the PDT which contains information about the current status of 
the device as well as Information about how it was configured 
during system generation. The DSRTPD DIB has the following 
structure : 

DENOTES FIELDS INITIALIZED BY SYSGEN 


DIBACR DATA 0 
DIBHWR BYTE 0 

■k 

■k 


*ACU CRU ADDRESS( >FFFF IF NONE) 
^INTERFACE TYPE 
1=C0MM/IF 
2=FCCC 
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* 



3=BCAIM 

* 



4=HSCC 

* 



5=TTY/EIA 

* 



6=9902 


BYTE 

0 

RESERVED 

DIBRTO 

DATA 

0 

*READ TIMEOUT (IN 1/4 SECONDS) 

DIBWTO 

DATA 

0 

*WRITE TIMEOUT(IN 1/4 SECONDS) 

DIBDTl 

DATA 

0 

*FIRST DIRECT TIMEOUT (IN 1/4 SEC) 

DIBDT2 

DATA 

0 

*SECOND DIRECT TIMEOUT (IN 1/4 SEC) 

DIBGFL 

FLAGS 

8 

*SYSGEN FLAGS (SAME AS DIBTFL) 


FLAG 

GFLECO 

ECHO (l=NO ECHO) 


BITS 

1 

UNUSED 


FLAG 

GFLXPE 

XMIT PARITY ENABLED( 1=ENABLED) 


BITS 

2 

XMIT PARITY TYPE 

* 



00=EVEN 

* 



01=0DD 

* 



10=MARK 

* 

FLAG 

GFLRPE 

1 1=SPACE 

RECEIVE PARITY ENABLED 


BITS 

2 

RECEIVE PARITY TYPE 

DIBSTF 

FLAGS 

8 

STATE FLAGS 


FLAG 

STFONL 

0=ONLINE 


FLAG 

STFCIP 

l=CONNECT IN PROGRESS 


FLAG 

STFOPN 

2=OPEN 


FLAG 

STFDLE 

3=DLE RECEIVED 


FLAG 

STFHDX 

4=HDUX LINE BELONGS TO REMOTE 


FLAG 

STFRSD 

5=RESEND FLAG 

6=UNUSED 

7-8=BIT DATA QUEUEING 

DIBLNF 

FLAGS 

8 

*LINE FLAGS 


FLAG 

LNFHDX 

*HALF DUPLEX ( 1=HALF DUPLEX) 


FLAG 

LNFSWT 

*SWITCHED LINE (1=SWITCHED) 


FLAG 

LNFRCL 

REFUSE CALL 


FLAG 

LNFADE 

AUTO-DISCONNECT ENABLED 


FLAG 

LNFDLE 

DLE/EOT FOR DISCONNECT 


FLAG 

LNFSCF 

SCF READY/BUSY MONITOR 


FLAG 

LNFEXC 

FILE XFER EXCLUSIVE ACCESS 


FLAG 

LNFHDL 

HALF DUPLEX LTA ENABLE 

DIBTFL 

FLAGS 

8 

TEMPORARY ACCESS FLAGS 


FLAG 

TFLECO 

ECHO ( l=NO ECHO) 


BITS 

1 

UNUSED 


FLAG 

TFLXPE 

XMIT PARITY ENABLED 


BITS 

2 

UNUSED 


FLAG 

TFLRPE 

RECEIVE PARITY ENABLED 

DIBSPD 

BYTE 

0 

*BAUD RATE (SPEED) 

* 



-1=300 OR 1200 SELECTED 

* 



BY 212 MODEM 

* 



0=110 

* 



1 = 300 

* 



2=600 

* 



3=1200 

* 



4=2400 

* 



5=4800 
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* 


DIBEOR BYTE 0 
DIBEOF BYTE 0 
DIBLTA BYTE 0 
DIBSUB BYTE 0 
DIBDLA BYTE 0 
DIBPCR DATA 0 
DIBPSR DATA 0 
DIBMXC DATA 0 
DIBTRM BYTE 0 
DIBLCR BYTE 0 
DIBXFL FLAGS 16 
DIBSVE BYTE 0 
DIBGSP BYTE 0 
DIBISR DATA 0 
DIBGTO DATA 0 
DIBPEC DATA 0 
DIBLCC DATA 0 
DIBSIZ EQU $-DIBBGN 


6=9600 

*END OF RECORD (=CR) 

*END OF MEDIUM (=EM) 

*LINE TURNAROUND (=EOT) 

^PARITY ERROR SUBSTITUTE (='?') 
CARRIAGE RETURN DELAY INTERVAL 
PARITY CHECK ROUTINE ADDRESS 
PARITY SET ROUTINE ADDRESS 
MAXIMUM CHARACTERS BUFFERED 
^TERMINAL TYPE (=TYPE-700) 

LAST CHARACTER RECEIVED 
SAVED EXTENDED FLAGS 
SAVED ERROR CODE FROM DSR 
^CURRENT SPEED (SAME AS DIBSPD) 
RESERVED 

*GENNED TIMEOUT(IN 1/4 SECONDS) 
NUMBER OF PARITY ERRORS 
NUMBER OF LOST CHARACTERS 
SIZE OF DIB 


10.4.3 DSRTPD Functions. 

The DSR has a power up entry point labelled PWRON. Powerup 
processing consists of copying default parameters to the DIB, 
setting the state of the Interface module accordingly, and 
setting values for the EIA lines which are appropriate to the 
line mode : 

1. For switched lines, all lines are forced low until Ring 
Indicate Is sensed or until the modem's online signal 
Is detected: Data Carrier Detect for full duplex. Data 
Set Ready for half-duplex. Because DCD Is not present 
for the 9902 port on the / lOA controller, switched line 
is not supported for that configuration. 

2. For unswltched lines. Data Terminal Ready Is asserted 
and the DSR looks for Data Set Ready before each 
character is transmitted. 


The DSR has an abort I/O entry point labelled ABORT. Abort I/O 
processing consists of terminating any I/O In progress with the 
abort error code (>10) and returning the DSR to the Idle state. 
Timeouts appear to DNOS to be disabled, but the DSR handles 
timeouts internally. 

10.4.4 DSRTPD Details. 

DSRTPD is built of five modules: DSRTPD, DSCOMISR, DSTTYISR, 
DSISR402, and DSTPDCOM. The DSR uses a vector table to access 
various har dwa re -r e 1 a t e d functions. 
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DSRTPD 

This module Is the request processor Interface. Its code is 
completely hardware Independent. When a hardware -dependent 
function needs to be performed, it goes through a vector 
table and enters the appropriate hardware -dependent module. 
This module uses the PDT workspace exclusively. It 
maintains a set of state tables that are used to control 
Interrupt-driven functions. 

DSCOMI SR 

The COMM board driver module Is named DSCOMISR. It contains 
code that Is executed from both the PDT and KSB workspaces. 

DSTTYISR 

The TTY/EIA driver Is called DSTTYISR. 

DSISR402 

All 9902 controllers (CI402, CI421, CI422, IlOA 9902 port) 
use this hardware driver. It contains code that Is executed 
from both PDT and KSB workspaces. 

DSTPDCOM 

This module performs character processing for DSTTYISR, 
DSCOMISR and DSISR402. It is entered when read Interrupts 
are detected. This module places characters In the KSB flfo 
In such a way that event and Katakana characters are 
recognl zeable to DNOS. When reads are outstanding to the 
port, it enters DSRTPD at the Interrupt level via a BLWP for 
processing the Read request. 

Vector Table 

The vector table contains entries for discrete hardware- 
related functions. A subroutine call to a fixed table 
offset Indexed by the table address Is sufficient to 
transfer Into hardware-dependent code. Vector table entries 
are provided for the following functions: 

1. Initialize power up 

2. Disconnect 

3. Control half-duplex Modem 

4 . Select speed 

5. Output 8-bit characters 

6. Report carrier and Data Set Ready status 

7. Read interface Image 

8. Write interface image 
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9. Start timer and schedule completion processor 

10. Decode interrupt and service through state table 

11. Monitor line for Incoming call 

12. Establish connection 

13. Abort without waiting to drop RTS 

10.4.5 DSRTPD Defaults. 

The defaults maintained by DSRTPD correspond to the current 990 
operating parameters for the terminal family and to the mode of 
operation used by DNOS utilities (such as SCI). 

Parameters pertaining to communication line management and to 
modem operation default to the following set: 

1. Accept incoming call. 

2. Disconnect on receipt of DLE EOT. 

3. Transmit even parity 

4. Set receive parity bit to 0. 

5. End of record character = CR 

6. End of file character = EM 

7. LTA character = EOT 

8. Parity error substitute character = ? 


10.5 ASYNCHRONOUS DSR STRUCTURE 

A unique DSR structure has been designed for asynchronous device 
support. Information about this structure and the routines used 
to write a custom DSR can be found in the DNOS System 
Programme r ^ s Guide. The material in this manual is 
implementation detail about the asynchrous DSRs . The information 
in the DNOS System Programmer's Guide should be read before this 
section. 
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Figure 10-7 DSR Structure 
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The asynchronus DSR design separates controller and device 
support into different software modules. The DSR consists of 
three basic modules. The controller support is provided by the 
HSR (Hardware controller Service Routine) module. The device 
support is provided by the TSR (Terminal Service Routine) module. 
The ISR (Interrupt Service Routine) has Interrupt and high 
priority processing responsibility. Table 10-2 lists the basic 
functions of the DSR components. The functions are discussed in 
detail in the DNOS Systems Programme r '' s Guide . 

Table 10-2 Asynchronous DSR Module Functions 


TSR - TERMINAL * All DSR entry points 

SERVICE ROUTINE ( Reques t / Ini t ial , Power up, Abo r t / T Ime ou t , 

Delayed Reentry, and Interrupt Entry) 

* Request and completion reporting I/F to DNOS 

* Runs in PDT workspace 

* Provides software interface to device 

* Contains device-dependent logic 


ISR - INTERRUPT * Interface to HSR for interrupt processing 
SERVICE ROUTINE * High priority receive character processing 

* Runs in DSR Interrupt workspace 


HSR - CONTROLLER * 
SERVICE ROUTINE 

* 

* 

* 


Generic (subroutine) software interface 
to the controller hardware 
Contains all controller-dependent logic 
Contains all direct access to controller 
Emulation of buffered controller 
- Hardware/ Sof tware FIFOs 


There are two mechanisms for scheduling the TSR from an ISR: 

* Reenter-me 

* DSR priority schedule 

Both of these mechanisms enter the DSR in the PDT workspace. The 
DSR is reentered when the next system clock interval expires if 
the reenter-me mechanism is Invoked. Refer to the description of 
the reenter-me mechanism in the section on device I/O handling 
for further details. Another mechanism for scheduling DSR non- 
interrupt processing (TSR) from DSR interrupt processing (ISR) is 
the DSR priority schedule mechanism. This mechanism reenters the 
DSR after all Interrupt processing for the system is complete, 
but before the operating system task scheduler or any task 
executes. This is a more direct reentry path to the DSR. It is 
Intended only for the highest priority (non-interrupt) 
processing. If this mechanism is used arbitrarily, it can 
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interfere with high priority processing of other DSRs. 

Table 10-3 describes the requirements for DSR (TSR) entry points 
when the DSR priority schedule mechanism is used. The DSR 
priority schedule entry point is at relative address >14. 


Table 10-3 DSR/TSR Entry Points 


0000 

B 

Ohint 

0004 

B 

esiNT 

0008 

B 

@PWRUP 

OOOC 

B 

(SABORT 

0010 

B 

@TIM0UT 

0014 

B 

^REQUEST 

0018 

B 

@PRISCH 


Hardware Interrupt entry 
System interrupt entry 
Power-up entry 
I/O abort ent ry 
Timeout entry 
Request processing 
Priority scheduler entry 


Refer to the description of the DSR priority schedule mechanism 
in the section on Device I/O Handling for further details. Other 
Interface mechanisms between the TSR and ISR can be defined by 
the user within the constraints of the operating system. The 
Interface to the HSR will be defined in a separate section. Each 
class contains several subroutines. These subroutines provide 
one or more HSR functions. The other subroutines are documented 
in the DNOS Systems Programmer's Guide . A list of the HSR 
subroutine classes are as follows: 

* Power-up initialization. 

* Write output signal or function. 

* Read input signal or function. 

* Enable /di sable status change notification. 

* Transmit a character. 

* Write operational parameters. 

* Read operational parameters. 

* Request timer interval notification. 

* Controller Interrupt decoding. 

* CI403/CI404 UART direct access. 

The HSR consists of a set of subroutines. All HSR subroutines 
are called via branch and link (BL) instructions, and thus, use 
the caller's workspace during execution. Parameters required by 
the subroutines are passed to the HSR in workspace registers. 
Information is returned to the caller in one of two ways. Data 
is returned to the caller in workspace registers. Status 
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Information Is returned via alternate subroutine returns. The 
caller specifies alternate return addresses as operands of DATA 
assembler directives immediately following the BL subroutine 
call. 


BL (anSRSUB 
DATA ALTl 
DATA ALT2 

it -kick 


Subroutine Call 
First Alternate Return 
Second Alternate Return 
Normal Return (Code) 


The caller execution resumes at one of the alternate return 
addresses or at the normal return address (the Instruction 
following all alternate return DATA statements). The number of 
alternate returns varies for different HSR subroutines. 


Some general register conventions are followed by HSR 
subroutines. In general, RO and RIO are used as working 
registers by HSR subroutines. In general, these two registers 
are used when parameters are passed to or from the HSR. 
Exceptions will be noted for some HSR subroutines. R7, in most 
cases, is used as a pointer to the PDT. 


10.5.1 Data Structures Linkage. 

Figure 10-10 Illustrates data structure linkages for asynchronous 
DSRs. 


10.5.2 Data Structure Allocation. 

The PDT extension is divided into two segments. One segment is 
physically contiguous to the PDT, and it contains data requiring 
the most efficient access. The other segment contains data for 
which the increased access time is not as great a penalty 
relative to overall performance. The second segment must be 
accessed using long-distance instructions. Other data structures 
included in the long-distance extension are VDT screen images for 
screen image DSRs. 

All the data structures no t accessed via long-distance 
instructions are allocated during system generation. These data 
structures are available when the operating system is loaded into 
memory from disk. The long-distance data structures must be 
allocated during initial powerup code by the DSR. The method 
used for this allocation is described in the next section. 


10.5.3 PDT Extension Definitions. 

The section documents PDT extensions used by the asynchronous DSR 
to support specific devices and controllers. Software use of 
these data structures for a set of specific hardware is also 
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discussed. Controller information is documented for the 
following set of asynchronous controllers: 

* CI403/CI404 — Four channel multiplexers 

* CI401 — Communications Interface Module 

* 9902/9903 — TMS9902 and TMS9903 based controllers: 

- S300 Base Station 

- CI421 

- CI422 

- 990/10A 9902 port 

- CI402 


Extensions are also documented for the following set of 
peripheral devices: 

* 931 and 940 VDTs 

* Serial Printers 


10.5.3.1 Asynchronous Local PDT Extension. 

The asynchronous DSR structure requires a PDT extension as 
defined in Figure lO-ll. Table 10-4 contains a template used by 
source code to reference the local PDT extension. The pathname 
for this template is DSALLLEX. It is available in the DNOS 
directory <vol> . S$0SLINK. TEMPLATE. ATABLE with the other system 
data structure templates. Notice that the detailed descriptions 
Indicate a zero based index for the extension. However, in 
reality the extension entries will be accessed using an index 
relative to the beginning of the PDT as Is indicated by the DORG 
directive of the template In Table 10-4. 

This extension starts Immediately after the KSB. The first two 
words of this extension are used to access a second DSR data 
structure (PDT extension) outside the local address space of the 
DSR. The next five words, PDXFLG through PDXCP3 , are reserved 
for HSR use. The remaining local PDT extension words are for 
TSR/ I SR use . 

Detailed descriptions of asynchronous PDT extensions are 
presented In separate sections. There are descriptions for each 
controller type and each device type. 
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Hex . 
Byte 


>00 

+- 

1 

PDXSMB 

- 

LONG distance 

EXT. 

MAP 

BIAS 


— — + 

1 

>02 

1 

PDXSMP 

- 

LONG DISTANCE 

EXT. 

MAP 

1 

POINTER 1 

>04 

1 

PDXFLG 

- 

HSR PARAMETER 

BYTE 

0 



1 

1 

>05 

1 

PDXCHN 

- 

HSR PARAMETER 

BYTE 

1 



1 

>06 

1 

PDXCPl 

- 

HSR PARAMETER 

BYTES 2 & 

3 


1 

>08 

1 

PDXCP2 

- 

HSR PARAMETER 

BYTES 4 & 

5 


1 

>0A 

1 

PDXCP3 

- 

HSR PARAMETER 

BYTES 6 & 

7 


1 

>0C 

1 

1 

PDXCP4 

- 

TSR/ISR 

PARAMETER 

BYTES 

0 & 

1 

1 

>0E 

1 

1 

PDXCP5 

- 

TSR/ISR 

parameter 

BYTES 

2 & 

3 

1 

>10 

1 

1 

PDXCP6 

- 

TSR/ISR 

PARAMETER 

BYTES 

4 & 

5 

1 

>12 

1 

1 

PDXCP7 

- 

TSR/ISR 

parameter 

BYTES 

6 & 

7 

1 

>14 

1 

1 

PDXCP8 

- 

TSR/ISR 

PARAMETER 

BYTES 

8 & 

9 

1 

>16 

1 

1 

PDXCP9 

- 

TSR/ISR 

PARAMETER 

BYTES 

10 

& 

11 1 

>18 

1 

1 

PDXCPA 

- 

TSR/ISR 

parameter 

BYTES 

12 

& 

13 1 

>1A 

1 

1 

PDXCPB 

- 

TSR/ISR 

parameter 

BYTES 

14 

& 

15 1 

>1C 

1 

1 

PDXCPC 

- 

TSR/ISR 

parameter 

BYTES 

16 

6c 

17 1 

>1E 

1 

1 

PDXCPD 

- 

TSR/ISR 

PARAMETER 

BYTES 

18 

6c 

191 

>20 

1 

1 

PDXCPE 

- 

TSR/ISR 

parameter 

BYTES 

20 

6c 

21 1 

>22 

1 

1 

+ 

PDXCPF 

- 

TSR/ISR 

PARAMETER 

BYTES 

22 

6c 

23 1 
— + 


Figure 10-9 Asynchronous Local PDT Extension 
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Table 10-4 Asynchronous Local PDT Extension Template 



DORG 

KSBSIZ 


PDXSMB 

BSS 

2 

LONG DIST EXT MAP BIAS 

PDXSMP 

BSS 

2 

LONG DIST EXT MAP POINTER 

PDXFLG 

BSS 

1 

HSR MEMORY AREA 

PDXCHN 

BSS 

1 

II 

PDXFCT 

BSS 

2 

II 

PDXCP 1 

BSS 

2 

II 

PDXCP2 

BSS 

2 

II 

PDXCP3 

BSS 

2 

II 

PDXCP4 

BSS 

ti 

It 

2 

TSR/ISR MEMORY AREA 

It 

It 


II 

RORG 


II 


10.5.3.2 Asynchronous Long-Distance Device Extension. 

The asynchronous DSRs are designed to use a long-distance 
extension (Figure 10-12) for part of the PDT extension area. 
This memory must be accessed using long-distance instructions. 
The long-distance extension is divided into several areas as 
defined by the following figure (Table 10-5). The pathname for 
this template is DSALLREX. It is available in the DNOS directory 
<vol >. S $ OSL INK . TEMPLATE . ATABLE with the other system data 
structure templates. 

The first 32 bytes beginning with HSRBGN are reserved for HSR 
module use. The next 112 bytes provide memory for a software 
transmit FIFO maintained by the HSR for non-buffered controllers. 
(The only buffered asynchronous controllers are the CI403 and the 
CI404.) The remainder of the long-distance extension is for 
TSR/ISR use. Its size varies with the functions performed by the 
TSR and ISR modules. The example template defines areas for an 
implementation that keeps a memory copy of the screen image for 
VDT support. 48 bytes are for TSR/ISR use. The memory starting 
at SIBUFF can be used by the TSR to maintain a memory image of 
the CRT screen. 
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Hex . 
Byte 


>00 

+ 

1 HSRBGN - 

HSR PORTION OF 

EXTENSION 

--+ 

1 

>1F 

1 

1 

1 

(32 BYTES) 


1 

1 

1 

>20 

1 SWFBGN 

- SOFTWARE FIFO BEGIN 

1 

>8F 

1 

1 

1 

(112 BYTES) 


1 

1 

1 

>90 

1 

1 TSRBGN - TSR/ISR PORTION 

OF EXTENSION 

1 

>BF 

1 

1 

1 

(48 BYTES) 


1 

1 

1 

>C0 

1 SIBUFF 

- SCREEN IMAGE 

BUFFER 

1 

>83F 

1 

I 

1 

+ 

(1920 BYTES) 


1 

1 

1 

--+ 


Figure 10-10 Asynchronous Long-Distance PDT Extension 


Table 

10-5 

Asynchronous Long-Distance PDT Extension Template 


DORG 

0 



HSRBGN 

EQU 

$ 

HSR PORTION OF DEVICE 

EXTENSION 


BSS 

>20 

HSR DEPENDENT BLOCK 


HSREND 

* 

EQU 

$ 



SWFBGN 

EQU 

HSREND 

SOFTWARE XMIT FIFO 



BSS 

>70 



SWFEND 

■k 

EQU 

$ 



TSRBGN 

EQU 

SWFEND 

TSR PORTION OF DEVICE 

EXTENSION 


BSS 

>30 



TSREND 

k 

EQU 

$ 



SIBUFF 

EQU 

TSREND 

SCREEN IMAGE BUFFER 



BSS 

>780 

1920 BYTE SCREEN IMAGE 

BUFFER 

SIEND 

EQU 

RORG 

$ 
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10. 5.3. 3 CI401 HSR Local Extension. 

Hex. Field 

Byte Name Description 

>00 PDXSMB This word contains the Inverted value of the 

byte count requested for the long distance 
buffer. The DSR Initializes this word during 
the power-up sequence. 

>02 PDXSMP This word contains the beet bias address of 

the long distance buffer requested by the DSR 
during the power-up sequence. The DSR 
requests the buffer by calling the system 
routine lOGUB. 

>04 PDXFLG This byte contains bit flags for the CI401 

HSR. The flags are defined as follows: 

Bit 0 Controller Master Reset Failed. This flag Is 
set to one during HSR power-up processing 
when a controller hardware failure Is 
detected. This flag Is also set to one If 
the controller Is not present In the chassis. 
This flag Is monitored by HSR Interrupt 
processing as a means of gracefully handling 
controllers that are Included as part of the 
configuration during system generation but 
which are not physically present In the 
chassis. This only becomes Important when 
the controller In question Is sharing an 
Interrupt level with other controllers that 
are present In the chassis. 

Bit 1 Secondary Data Carrier Detect (SDCD) State. 

This flag Is set to one when the current 
state of the SDCD signal Is on (logic 1) and 
Is set to zero when the current state of the 
SDCD signal Is off (logic 0). 

Bit 2 Reserved . 

Blt3 Reserved. 

Bit 4 Reserved . 

Bit 5 Secondary Data Character Detect Notify Flag. 

This flag Indicates If notification of status 
change has been requested. This flag is set 
to one when the HESSDC HSR subroutine is 
called to enable notification of status 
change. This flag Is set to zero when the 
HDSSDC subroutine Is called to disable 
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notification of status change. 

Bit 6 Reserved . 

Bit 7 Reserved . 

>05 PDXCHN This byte contains bit flags for the CI401 

HSR. The flags are defined as follows: 

Bit 0 Data Carrier Detect (DCD) State. This flag 
is set to one when the current state of the 
DCD signal is on (logic 1) and is set to zero 
when the current state of the DCD signal is 
off (logic 0). 

Bit 1 Ring Indicator (RI) State. This flag is set 

to one when the current state of the RI 

signal is on (logic 1) and is set to zero 
when the current state of the RI signal is 
off (logic 0). 

Bit 2 Data Set Ready (DSR) State. This flag is set 
to one when the current state of the DSR 
signal is on (logic 1) and is set to zero 
when the current state of the DSR signal is 
off (logic 0 ) . 

Bit 3 Clear To Send (CTS) State. This flag is set 

to one when the current state of the CTS 

signal is on (logic 1) and is set to zero 
when the current state of the CTS signal is 
off (logic 0). 

Bit 4 Data Character Detect (DCD) Notify Flag. 

This flag Indicates if notification of status 
change has been requested. This flag is set 
to one when the HESDCD HSR subroutine is 
called to enable notification of status 
change. This flag is set to zero when the 
HDSDCD subroutine is called to disable 
notification of status change. 

Bit 5 Ring Indicator (RI) Notify Flag. This flag 

indicates if notification of status change 
has been requested. This flag is set to one 
when the HESRI HSR subroutine is called to 
enable notification of status change. This 
flag is set to zero when the HDSRI subroutine 
is called to disable notification of status 
change . 

Bit 6 Data Set Ready (DSR) Notify Flag. This flag 

indicates if notification of status change 
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has been requested. This flag Is set to one 
when the HESDSR HSR subroutine Is called to 
enable notification of status change. This 
flag Is set to zero when the HDSDSR 

subroutine Is called to disable notification 
of status change. 

Bit 7 Clear To Send (CTS) Notify Flag. This flag 
Indicates If notification of status change 
has been requested. This flag Is set to one 
when the HESCTS HSR subroutine is called to 
enable notification of status change. This 
flag Is set to zero when the HDSCTS 

subroutine Is called to disable notification 
of status change. 

>06 PDXFCT This word contains the entry byte count for a 

software transmit FIFO maintained by the HSR. 

>08 PDXCPl This word contains the insertion pointer for 

the software FIFO maintained by the HSR, It 
contains the address of the next FIFO 

location In which to store a transmit 

character . 

>0A PDXCP2 This word contains the removal pointer for 

the software transmit FIFO maintained by the 
HSR. It contains the address of the next 
transmit FIFO entry to be removed. 

>0C PDXCP3 This word Is used by the HSR as a transmit 

state vector. It contains an address of an 
HSR transmit routine. The HSR changes this 
address as the HSR transmit state changes. 

>0E->24 PDXCP4 Reserved for TSR/ISR usage. 

10.5.3.4 CI401 HSR Long-Distance Extension. 

Hex . Field 

Byte Name Description 

>00 EXTTMR HSR timer word. This word is counted down, 

or decremented, once every 250 milliseconds 
until It reaches zero. The ISR Is notified 
of timer expiration when this value is 
decremented to zero. The timer count is set 
by calling the HSR routine HTIMER, 

>02 EXTFLG This word is used as a bit flag word by the 

HSR. The flag definitions are as follows: 

Bit 0 Channel transmit halt flag. When this flag 
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is set to one, the HSR accepts transmit data 
from the TSR/ISR until the software FIFO 
fills, but does not transmit data on the 
communication line. This flag is set to one 
by a call to the HSTCTH HSR subroutine. It 
is set to zero by a call to the HRTCTH HSR 
subroutine. 

Bit 1 This flag indicates the mode of the HSR. 

When this flag is set to one, the channel is 
in a channel reset mode. A call to the HSTCR 
HSR subroutine sets this flag to one. Once 
in the channel reset mode, a call to the 
HRTCR (Reset channel reset mode) HSR 
subroutine is required to set the flag to 
zero and restore the HSR to normal operation. 
When in the channel reset mode , no CI401 
interrupts are enabled. 

Bit 2--F Reserved. 

>04 EXTTMP This word is used as a temporary storage word 

by HSPPSL and HSPSPD subroutines. 

>06 EXTSPD This word contains the speed selection code. 

It contains the value passed as a parameter 
to the HSPSPD subroutine. The contents of 
this word are returned by the HSR subroutine 
HRPSPD. 

>08 EXTPSL This word contains the data format 

parameters. It contains the value of the 
parameters passed to the HSR subroutine 
HSPPSL. The contents of this word are 
returned to the caller of the HSR subroutine 
HRPPSL. 

>0A EXTFLl This word contains a receive data mask. The 

mask value is set by the HSR subroutine 
HSPPSL. The mask value is used by the HSR 
receive data processing routine to isolate 
the receive data bits. 


>oc 

EXTFL2 

This word is used as 
by the HSR subroutine 

a temporary storage 
HSTCR. 

word 

>0E 

EXTFL3 

Reserve d . 




>10 

EXTOVR 

This word is used as 
counter by the HSR, 

a re ce i ve 

ove r r un 

error 

>12 

EXTFER 

This word is used as 

a receive 

framing 

error 


counter by the HSR, 
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>14 EXTPER This word is used as a receive parity error 

counter by the HSR, 


10.5.3.5 CI403/CI404 HSR Local Extension. 

Hex . Field 

Byte Name Description 

>00 PDXSMB This word contains the inverted value of the 

byte count requested for the long distance 
buffer* The DSR initializes this word during 
the power-up sequence, 

>02 PDXSMP This word contains the beet bias address of 

the long distance buffer requested by the DSR 
during the power-up sequence. The DSR 
requests the buffer by calling the system 
routine lOGUB, 

>04 PDXFLG This byte contains bit flags for the 

CI403/CI404 HSR. The flags are defined as 
follows: 

Bit 0 Transmit in hold. This flag is set to one 
whenever one or both of the following 
conditions exists: the common transmit FIFO 

is near full, or the channel -sped f Ic 
transmit FIFO is full. This flag bit 0 is 
reset whenever all holding conditions have 
been satisfied. See the explanation below 
for bits 2 and 3 • 

Bit 1 Reserved • 

Bit 2 Controller transmit hold. Whenever the 

common transmit FIFO is near full, the 
controller issues the halt transfer status 
(status 4, substatus 1) to the HSR; this bit 
is set to one, and bit 0 is set to one. Bit 
2 is reset when the common transmit FIFO is 
empty and the controller Issues the resume 
transfer status (status 4, substatus 2) to 
the HSR. 

Bit 3 FIFO exhausted transmit hold. Whenever the 
HSR FIFO count goes to zero, the HSR sets 
this bit to one, sets bit 0 to one, and 
enables transmit FIFO empty interrupt. The 
HSR resets bit 3 whenever the controller 
notifies the HSR that the channel specific 
FIFO is empty . 
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Bit 4 Data Character Detect (DCD) notification 

flag. This bit is set to one when the 
TSR/ISR calls the HSR subroutine HESDCD to 
enable notification of DCD status changes. 
This bit is set to zero when the HDSDCD 
subroutine is called to disable notification 
of DCD status changes. 

Bit 5 Ring Indicator (RI) change notification flag. 

This bit is set to one when the TSR/ISR calls 
the HSR subroutine HESRI to enable 

notification of RI status changes. This bit 
is set to zero when the HDSRI subroutine is 
called to disable notification of RI status 
changes. 

Bit 6 Data Set Ready (DSR) change notification 

flag. This bit is set to one when the 
TSR/ISR calls the HSR subroutine HESDSR to 
enable notification of DSR status changes. 
This bit is set to zero when the HDSDSR 
subroutine is called to disable notification 
of DSR status changes. 

Bit 7 Clear To Send (CTS) change notification flag. 

This bit is set to one when the TSR/ISR calls 
the HSR subroutine HESCTS to enable 

notification of CTS status changes. This bit 
is set to zero when the HDSCTS subroutine is 
called to disable notification of CTS status 
changes . 

>05 PDXCHN This byte contains the channel number of the 

CI403/CI404. It is specified during system 
generation and initialized by the system 
generation program. 

>06 PDXFCT This word contains the byte count of the 

available CI403/CI404 channel-specific 

transmit FIFO as maintained by the HSR. This 
word is not necessarily an accurate 

representation of the actual state of the 
controller FIFOs. 

>08 PDXCPl This word contains bit flags for the 

CI403/CI404 HSR. The flags are defined as 
follows : 

Bit 0 Reset mode. This flag is set to one when the 
TSR/ISR calls the HSR subroutine HSTCR to 
reset a particular channel. While this bit 
is set to one, all controller interrupts are 
ignored. This bit is reset to zero when the 
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TSR/ISR calls the HSR subroutine HRTCR to 
allow controller Interrupts, 

Bit 1 Secondary Data Character Detect (SDCD) change 
notification flag. This bit is set to one 

when the TSR/ISR calls the HSR subroutine 
HESSDC to enable notification of SDCD status 
changes. This bit Is set to zero when the 
HDSSDC subroutine Is called to disable 

notification of SDCD status changes. 



Bit 2-r 

Reserved. 

>0A 

PDXCP2 

Reserved . 

>0C 

PDXCP3 

Reserved • 

>0E->24 

PDXCP4 

Reserved for TSR/ISR usage. 

10.5.3.6 

CI403/CI404 HSR Long-Distance Extension. 

Hex . 

Field 


Byte 

Name 

Description 

>00 

EXTTMR 

HSR timer duration value. This word Is 
decremented once every 250 milliseconds until 
it reaches zero. The TSR/ISR is notified of 
timer expiration when this value Is 
decremented to zero. The timer count is set 
by calling the HSR subroutine HTIMER. 

>02 

EXTRG3 

This word contains a copy of the ACE register 
3 contents for the specified channel. 

>04 

EXTRG4 

This word contains a copy of the ACE register 
4 contents for the specified channel. 

>06 

EXTRG7 

This word contains a copy of the ACE register 
7 contents for the specified channel. 

>08 

EXTSPD 

This byte contains a copy of the speed code 
that Is currently programmed in the ACE. If 
the TSR/ISR specified an Illegal speed then 
this byte contains an >FF. The second byte 
of the word is reserved. 

>0A 

EXTRO 

This word contains a copy of the TSR's RO 
whenever the HSR is delaying after a write to 
an ACE register. 

>0C 

EXTR7 

This word contains a copy of the TSR's R7 
whenever the HSR Is delaying after a write to 
an ACE register. 
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>0E EXTRll This word contains a copy of the TSR's Rll 

whenever the HSR is delaying after a write to 
an ACE register. 

10.5.3.7 9902/9903 HSR Local Extension. 

Hex. Field 

Byte Name Description 

>00 PDXSMB This word contains the Inverted value of the 

byte count requested for the long distance 
buffer. The DSR initializes this word during 
the power-up sequence. 

>02 PDXSMP This word contains the beet bias address of 

the long distance buffer requested by the DSR 
during the power-up sequence. The DSR 
requests the buffer by calling the system 
routine lOGUB. 

>04 PDXFLG This byte contains bit flags for the 

9902/9903 HSR. The flags are defined as 
follows : 

Bit 0 Data Carrier Detect (DCD) State. This flag 
is set to one when the current state of the 
DCD signal is on (logic 1), and is set to 
zero when the current state of the DCD signal 
is off (logic 0). 

Bit 1 Ring Indicator (RI) State. This flag is set 

to one when the current state of the RI 

signal is on (logic 1), and is set to zero 

when the cur- rent state of the RI signal is 

off (logic 0). 

Bit 2 Data Set Ready (DSR) State. This flag is set 
to one when the current state of the DSR 
signal is on (logic 1), and is set to zero 
when the current state of the DSR signal is 
off (logic 0). 

Bit 3 Clear To Send (CTS) State. This flag is set 

to one when the current state of the CTS 

signal is on (logic 1), and is set to zero 
when the current state of the CTS signal is 
off (logic 0). 

Bit 4 Data Character Detect (DCD) Notify Flag. 

This flag indicates if notification of status 
change has been requested. This flag is set 
to one when the HESDCD HSR subroutine is 
called to enable notification of status 
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change. This flag is set to zero when the 
HDSDCD subroutine is called to disable 
notification of status change. 

Bit 5 Ring I ndl ca t or ( RI ) Notify Flag. This flag 
indicates if notification of status change 
has been requested. This flag is set to one 
when the HESRI HSR subroutine is called to 
enable notification of status change. This 
flag is set to zero when the HDSRI subroutine 
is called to disable notification of status 
change . 

Bit 6 Data Set Ready (DSR) Notify Flag. This flag 

indicates if notification of status change 
has been requested. This flag is set to one 
when the HESDSR HSR subroutine is called to 
enable notification of status change. This 
flag is set to zero when the HDSDSR 

subroutine is called to disable notification 
of status change. 

Bit 7 Clear To Send (CTS) Notify Flag. This flag 

indicates if notification of status change 
has been requested. This flag is set to one 
when the HESCTS HSR subroutine is called to 
enable notification of status change. This 
flag is set to zero when the HDSCTS 

subroutine is called to disable notification 
of status change. 

>05 PDXCHN This byte contains bit flags for the 

9902/9903 HSR. The flags are defined as 
follows : 

Bit 0 Reserved. 

Bit 1 Secondary Data Carrier Detect (SDCD) State. 

This flag is set to one when the current 

state of the SDCD signal is on (logic 1), and 
is set to zero when the current state of the 
SDCD signal is off (logic 0). 

Bit 2 Transmit Shift Register Empty (TSRE) State. 

This flag is set to one when the current 

state of the TSRE signal is on (logic 1), and 
is set to zero when the current state of the 
TSRE signal is off (logic 0). 

Bit 3 Reserved. 

Bit 4 Re served. 
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Bit 5 Secondary Data Character Detect Notify Flag. 

This flag Indicates if notification of status 
change has been requested. This flag Is set 
to one when the HESSDC HSR subroutine Is 
called to enable notification of status 
change. This flag Is set to zero when the 
HDSSDC subroutine Is called to disable 
notification of status change. 

Bit 6 Transmit Shift Register Empty (TSRE) Notify 
Flag. This flag Indicates If notification of 
status change has been requested. This flag 
is set to one when the HESTSR HSR subroutine 
Is called. This flag Is set to zero when the 
HDSTSR subroutine is called. 



Bit 7 

Reserved . 






>06 

PDXFCT 

This 

word 

contains 

the 

entry byte 

count 

for a 



s of tware 

transmit 

FIFO 

ma intalned 

by the 

HSR. 

>08 

PDXCPl 

This 

wo rd 

contains 

the 

Insertion 

pointer 

for 



the 

software FIFO 

maintained by 

the HSR 

. It 



contains 

the address 

of the 

next 

FIFO 


location In which to store a transmit 
character. 

>0A PDXCP2 This word contains the removal pointer for 

the software transmit FIFO maintained by the 
HSR. It contains the address of the next 
transmit FIFO entry to be removed. 

>0C PDXCP3 This word is used by the HSR as a transmit 

state vector. It contains an address of an 
HSR transmit routine. The HSR changes this 
address as the HSR transmit state changes. 

>0E->27 PDXCP4 Reserved for TSR/ISR usage. 

10.5.3.8 9902/9903 HSR Long-Distance Extension. 

Hex . Field 

Byte Name Description 

>00 EXTTMR HSR timer word. This word is decremented 

once every 250 milliseconds until it reaches 

zero. The ISR Is notified of timer 
expiration when this value is decremented to 
zero. The timer count is set by calling the 
HSR routine HTIMER. 

>02 EXTCDY HSR timer word. This word is decremented 

approximately once every 16 milliseconds 
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until It reaches zero. The EXTTMR word Is 
then decremented, and this word is restored 
from EXTCST. 

>04 EXTCST HSR timer word. This word is loaded at 

Initial DSR power-up entry to be used to 
determine how many 9902/9903 timer interrupts 
are required to time 250 milliseconds. 

>06 EXTFLG This word is used as a bit flag word by the 

HSR. The flag definitions are as follows: 

Bit 0 Channel transmit halt flag. When this flag 
is set to one the HSR accepts transmit data 
from the TSR/ISR until the software FIFO 

fills, but does not transmit data on the 
communication line. This flag is set to one 
by a call to the HSTCTH HSR subroutine. It 
is set to zero by a call to the HRTCTH HSR 
subroutine . 

Bit 1 This flag indicates the mode of the HSR. 

When this flag is set to one the channel is 
in a channel reset mode. A call to the HSTCR 
HSR subroutine sets this flag to one. Once 
in the channel reset mode, a call to the 
HRTCR (Reset channel reset mode) HSR 
subroutine is required to set the flag to 
zero and restore the HSR to normal operation. 
When in the channel reset mode, no 9902/9903 
interrupts are enabled. 

Bit 2 UART Internal Loopback Enabled Flag. This 
flag is set to one when the TSR requests that 
the 9902/9903 chip be placed in UART loopback 
mode. This bit is set to one by a call to 
the HSTUIL HSR subroutine. It is set to zero 
by a call to the HRTUIL HSR subroutine. 

Bit 3 Transmit Break Enabled Flag. This flag is 
set to one when the TSR requests that the 
9902/9903 chip transmit a break condition. 
This bit is set to one by a call to the HSTTB 
HSR subroutine. It is set to zero by a call 
to the HRTTB HSR subroutine. 

Bit 4-F Reserved. 

>08 EXTTMP This word is used as a temporary storage word 

by the HSR. 

>0A EXTTMl This word is used as a temporary storage word 

by the HSR. 
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>0C 

>0E 

>10 

>12 

>14 

10.5. 

Hex . 
Byte 

>00 

>02 

>04- 

>0E 

I/O 


EXTSPD This word contains the speed selection code. 

It contains the value passed as a parameter 
to the HSPSPD subroutine. The contents of 
this word are returned by the HSR subroutine 
HRPSPD. 

EXTPSL This word contains the data format 
parameters. It contains the value of the 
parameters passed to the HSR subroutine 
HSPPSL. The contents of this word are 
returned to the caller of the HSR subroutine 
HRPPSL. 

EXTLDC This word contains the CRU Instruction 
required to load the 9902/9903 UART with 
transmit data for the communications line. 

EXTTYP This word Is set up at Initial DSR entry on 
power-up, to define the hardware Interface 
type as f ol lows : 


Value 


Port 


Devi ce Type 


0 

2 

4 

6 

8 

>A 


990/10A 9902 
CI402 9902 
CI421 9902 
CI422 9902 

S300 Base Station 9902 
CI421 9903 


>0007 

>0008 

>0009 

>000A 

>0006 

>0030 


to >BF 


These words 
de ve lopment . 


are reserved for future HSR 


3.9 931/940 TSR/ISR Local Extension. 


Field 

Name 


Description 


PDXSMB This word contains the Inverted value of the 
byte count requested for the long distance 
buffer. The DSR Initializes this word during 
the power-up sequence. 

PDXSMP This word contains the beet bias address of 
the long distance buffer requested by the DSR 
during the power-up sequence. The DSR 
requests the buffer by calling the system 
routine lOGUB. 


>0D 


HSR Information. 


PDXCP4 System generation puts In this word the 
location of RO of the attached printer If one 
Is present. At power-up time, this is moved 
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to the remote extension, and the word is used 
as the TSR's copy of the IRB extended user 
flags . 

>10 PDXCP5 System generation puts in this word the speed 

of the communication line and a flag 

indicating if the line is a dial-in line. At 
power-up time, this is moved to the remote 
extension, and the word is used as the 
current cursor position by the TSR. 

>12 PDXCP6 This word is a TSR flag word. 

Bit 0 Terminal Type. This flag is set to one if 

the terminal is a 931 and set to zero if it 
is a 940 . 

Bit 1 Read Schedule. This flag is set to one when 

the TSR requests to be resecheduled upon 
receipt of a read character. 

Bit 2 Printer Has Channel. This flag is set to one 
when the printer has control of the channel. 

Bit 3 Printer Wants Channel. This flag is set to 

one when the printer requests control of the 
channel, and the CRT currently has control of 
the channel. 

Bit 4 CRT Has Channel. This flag is set to one 
when the CRT has control of the channel. 

Bit 5 CRT Wants Channel. This flag is set to one 

when the CRT requests control of the channel, 
and a printer currently has control of the 
channel . 

Bit 6 Cursor Is On. This flag is set to one when 
the cursor is on. 

Bit 7 Cursor Not ]^een Moved. This flag Indicates 

that the cursor is not physically at the 
location that the internal pointer says it is 
located. This is to avoid sending 

unnecessary commands. 

Bit 8 Graphics Flag. This flag indicates that the 
command has been made to the terminal to be 
in graphics mode. 

Bit 9 Graphics Input Flag. This flag indicates 

that the terminal has notified the host that 
Input from the terminal will be In graphics 
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mode • 

Bit 10 Reserved. 

Bit 11 Clear Flag. This flag Indicates that the 

screen has been cleared and nothing has yet 
been sent to It. This is to avoid sending 
unnecessary commands. 

Bit 12 Cursor is Blinking. This flag is set to one 
when the cursor is blinking. 

Bit 13 Initialized Flag. This flag indicates that 
the terminal has been initialized. 

Bit 14 Extent Flag. This flag Indicates that the 

command has been made to the terminal to 
define the end of the current field for 
Insert and delete. 

Bit 15 Insert Flag. This flag indicates that the 

TSR is in Insert mode. 

>14 PDXCP7 This word is used as an internal buffer 

address by the TSR. 

>16->1A PDXCP7-A These words are temporary save locations for 

the TSR. 

>1C PDXCPB This word contains the current attribute sent 

to the terminal. 

>1E PDXCPC This word contains the counter for the 

optimization routine. 

>20 PDXCPD This word contains an Internal TSR counter. 

>22 PDXCPE This word is an opcode 15 flag. 

Bit 0 Pass Through. This flag is set to one when 

the data is to be sent and received with no 
conversion. The only characters that are 

acted upon are DCl and DCS ( ready /busy ) . 

Bit 1 ETX Flag. Terminate a Pass Through Read on 

receipt of an "ETX" character. 

Bit 2 ESC Flag. Terminate a Pass Through Read on 
receipt of an "ESC )" character string. 

Bit 3 Extended Event Flag. This flag allows the 
extra 940 characters to be entered. 
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Bit 4 Reserved. 

Bit 5 Special Attribute Flag. This flag is set to 
one when the the TSR will allow "SI", "SO", 
or "ESC 4" to be sent to the terminal from a 
user buffer. 

Bit 6 Disable Attributes. This flag means that no 
attributes are to be sent to the terminal by 
the TSR. 

Blt7 Reserved. 

Bit 8 Modified Flag. This flag indicates that if 

any data has been modified in a field, the 

task should be notified. 

Bit 9 Extended Character Validation. This flag 
indicates that the character validation is to 
be handled before the character is echoed. 

Bit 10 Null Truncation flag. 

Bits 11-15 Reserved. 


>24 

PDXCPF 

This word contains the current state of input 
as follows: 



Value Meaning 

0 Ignore input and do not produce output 



4 Accept input and produce output. 

10.5.3.10 

931/940 

TSR/ISR Long-Distance Extension. 

Hex . 

Field 


Byte 

Name 

Description 

>00->8F 


HSR Words. 

>90 

VDTFIL 

This byte contains the current fill 

character . 

>91 

VDTEVT 

This byte contains the event character that 
terminated the read. 

>92 

VDTDEF 

This word contains the sequential cursor 

position of the beginning of the current 


field . 


>94 VDTPSR This word is a temporary location for the 

printer portion of the TSR. 
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>96 


>97 

>98 

>9A 


>9C 


VDTPTP This byte contains the current printer type 
as follows: 


Bit 0 


Value 

0 

1 

2 

3 

4 


Meaning 
150 cps 

7 5 cps 

40 cp s 

20 cps 

300 cps 


Re served • 

Run-time location for speed in PDXCP5 . 

Mask to determine if the terminal 
connected • 

Value Meaning 


>A000 DCD and DSR 

>2000 DSR only 


Remote Flags : 
Reserved . 


is 


Bit 1 Blinking. This flag is set if blinking is 
allowed for the terminal (940 only). 

Bit 2 Wait for Positive Feedback. This flag is set 
when a printer buffer has been sent and the 
TSR is waiting for terminal acknowledgement 
(931 only). 

Bit 3 Schedule on Positive Feedback. This flag is 
set when a printer buffer has been sent and 
the TSR wants to be scheduled when the 

terminal acknowledges the buffer (931 only). 

Bit 4 Terminal has started power-up, but has not 

completed y et . 

Bit 5 An immediate open has occurred on the CRT, 
the next close will be an immediate close. 

Bit 6 An Immediate open has occurred on the 

printer, the next close will be an Immediate 
close . 
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Bit 

7-D 

Re s e rve d • 




Bit 

E 

ESC Found. This flag indicates that an 
was just found in a string in the TSR. 

ESC 


Bit 

F 

Re served . 



>9E 

VDTERR 

This word is used to pass an error 
the ISR to the TSR. 

code 

from 

>A0 

VDTOVR 

This word is a counter of the 
overrun errors detected. 

number 

of 

>A2 

VDTPAR 

This word is a counter of the 
parity errors detected. 

number 

of 

>A4 

VDTFRM 

This word is a counter of the 
framing errors detected. 

number 

of 

>A6 

VDTPTR 

Run-time location for printer 
PDXCP4. 

address 

in 

>A8 

PRTTIM 

Timer for printer delay (940 only) 

• 


>AA 

VDTEDL 

This word is an opcode 15 Edit Flag. 



Bi t 

0 

Erase Field is an Event. 




Bit 

1 

Right Field is an Event. 




Bi t 

2 

Cursor Left out of a Field is an Event. 



Bit 

3 

Tab is an Event . 




Bit 

4 

Reserved . 




Bit 

5 

Skip is an Event. 




Bit 

6 

Home is an Event. 




Bi t 

7 

Return is an Event. 




Bi t 

8 

Erase Input is an Event. 




Bit 

9 

Reserved . 




Bit 

A 

Delete Character is an Event. 




Bi t 

B 

Insert Character is an Event. 




Bi t 

C 

Cursor Right out of a Field is an 

Event . 



Bi t 

D 

Enter is an Event. 
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>AE 


>B0 


>B2 


10.5.3 

Hex . 
By te 

>00 

>02 


Bit E 
Bit F 
STATBD 


STATGR 


STATFN 


.11 Serial 

Field 

Name 


Left Field Is an Event. 


Re served. 

This word contains the state of the board as 
f ol lows : 


Value Meaning 


0 

Board 

dl s connected . 



4 

Board 

connected . 



8 

Boa rd 

waiting on timeout. 



12 

Board 

waiting on ring. 



16 

Board 

Is In DSR diagnostic 

mode 

• 

This word 
graphics. 

contains the state of 

the 

Input 

Value 

Meanl ng 



0 

Input 

Is not graphics . 



4 

Input 

Is graphics. 



This word 
mapping . 

contains the state of 

the 

key 

Value 

Meanl ng 




0 Regular keys. 

4 ESC was received. 


8 Aid was received. 

12 Pass Through Mode. 

16 DSR Diagnostic Mode. 

20 Read Status Mode. 


Printer HSR Local Extension. 


Descr 1 pt Ion 


PDXSMB This word contains the Inverted value of the 
byte count requested for the long distance 
buffer. The DSR Initializes this word during 
the power-up sequence. 

PDXSMP This word contains the beet bias address of 
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the long distance buffer requested by the DSR 
during the power-up sequence. The DSR 
requests the buffer by calling .the system 
routine lOGUB, 

>04 - >0F Reserved for HSR use. 

>10 PDXCP4 This byte contains bit flags for the serial 

printer HSR. The flags are defined as 
follows: 

Bit 0 Reserved . 

Bit 1 This bit, when set to one, indicates that a 

write SCB is being processed by the TSR. 

Bit 2 Reserved. 

Bit 3 This bit, when set to one, indicates that a 

non-write command is being processed by the 
TSR. 

Bit 4 This bit, when set to one, indicates that 

data transmission to the device has been 

stopped because the data set ready (DSR) 
signal is not present. 

Bit 5 This bit, when set to one, indicates that 

data transmission to the device has been 

stopped due to reception of a DC3 character 
from the device. 

Bit 6 This bit, when set to one, indicates that a 

KATAKANA mode select character is being 
transmitted. 

Bit 7 This bit, when set to one, indicates that the 
device supports extended print (lower case 
letters). 

Bit 8 Re s e r ve d . 

Bit 9 This bit, when set to one, Indicates that the 
ISR section has detected a condition that 
requires scheduling of the TSR section. 

Bit 10 Reserve d . 

Bit 11 Reserved. 

Bit 12 This bit, when set to one, indicates that the 
TSR is not able to operate due to some 
condition (hardware interface not present. 
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requested baud rate not supported by the 
hardware interface, power up failure, and so 
on ) . 



Bit 13 

This bit, when set to one, indicates that 

initial power-up has occurred. 


Bit 14 

Reserved . 


Bit 15 

Reserved . 

>12 

PDXCP5 

This word contains the transmit and receive 
baud rate word. This word is initialized by 
sysgen or the MVPC command. 

>14 

PDXCP6 

This word contains the operation parameter 
word for the hardware interface. 

>16 

PDXCP7 

This word contains the total error count seen 
by the TSR (the count of all parity errors, 
overrun errors, framing errors, and so on). 

10.5.3.12 

Serial 

Printer HSR Long-Distance Extension. 

Hex . 

Field 


Byte 

Name 

Description 

>00 - >8F 


These words are reserved for use by the HSRs. 

>90 

RTEXTO 

This word is a count of the number of receive 
break conditions sensed. 

>92 

RTEXTl 

This word is a count of the number of framing 
errors received. 

>94 

RTEXT2 

This word is a count of the number of parity 
errors received. 

>96 

RTEXT3 

This word is a count of the number of 
receiver overrun errors received. 

>98 

RTEXT4 

This word is a count of the number of other 
errors received. 

>9A 

RTEXT5 

This word is a count of the number of illegal 
UART Interrupts received. 

>9C - >BF 


These words are reserved for future ISR/TSR 


use • 
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10.6 I/O UTILITY (lOU) 

The Initial processing of a utility request Is similar to that 
for device I/O. The SVC Is decoded by RPROOT, which passes 
control to lOPREP, the I/O preprocessor. lOPREP passes control 
to the I/O Utility preprocessor, lUPREP, when It recognizes an 
lOU SVC. 

The lOU preprocessor buffers the call block and any extensions to 
the call block as required by the Individual subopcodes. Call 
block extensions Include pathname, key definitions, and 
parameters. The preprocessor checks for Illegal subopcodes and 
mapping errors during the buffering process. BRBs for SVCs that 
do not require an access name (or whose access name begins with a 
period) are placed directly on the Input queue for the lOU task. 
Other BRBs are first queued for the Name Manager task for 
resolution of any logical names. After logical name resolution. 
Name Manager places the BRB on the Input queue for the lOU task. 

The lOU task has a main driver that calls other routines to 
process the Individual lOU subopcodes. The lOU task consists of 
a root segment and three or four system overlays depending upon 
the sysgen options chosen. Assign LUNO, Release LUNO, and Delete 
File SVCs are handled by code in the lOU root segment. Create 
File SVCs are handled by code residing In one overlay; Add Allas, 
Delete Allas, and Rename <flle In a second overlay; and the 
remaining lOU SVCs are handled by code In the third overlay. A 
fourth overlay to handle security Is Included If the security 
option was chosen during sysgen. File security will be discussed 
In a separate section. The main driver, a stack, and subroutines 
required by all overlays are Included In the lOU root segment. 

When lOU Is activated. It dequeues an entry from Its queue and 
processes the entry. If the lOU SVC processor that handles the 
SVC resides In an overlay, the overlay Is loaded Into memory 
(unless It already resides In memory). The SVC processor Is 
called to perform the required operations; when It completes, 
control Is returned to the lOU main driver. The processing of 
the SVC may require that the BRB be queued for processing by a 
channel owner task. If so, the request Is passed to the IPC 
preprocessor for routing to the channel owner. 

The lOU main driver takes the appropriate exit path after the SVC 
processor has handled the SVC. If the request was queued to a 
channel owner, the BRB will be unbuffered later, after It has 
been processed by the channel owner and placed back on the lOU 
Input queue by IPC. If the SVC required the creation of a job 
temporary file, the BRB Is placed on the Input queue for Name 
Manager for final processing and unbufferlng. If neither of 
these special conditions exists, the BRB Is queued for 
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unbufferlng to the calling task, lOU then requests the next 
entry from Its queue. If the Input queue Is empty, lOU suspends, 
awaiting queue input. 

The range of lOU operations Includes those that process SVC 
requests to create and delete files, assign and release LUNOs , 
rename files, protect and unprotect files, add and delete aliases 
for filenames, and create and delete channels. lOU also 
processes requests for special operating system services such as 
releasing LUNOs In another job. 


10.6.1 Configurability. 

lOU Is configurable during sysgen when the user specifies the 
features desired. The modules to process these features are then 
selected for Inclusion In the lOU task. The following feature 
levels can be selected; 

* Dynamic KIF creation and deletion 

* File access security 


10.6.2 Memory Layout. 

lOU runs as a system task in map file 1. Its three map segments 
are used as follows; 

* The first segment contains the system root. 

* The second segment changes during processing and 
contains either the user JCA, the system job JCA, or a 
file management table area (FMT). 

* The third segment contains the lOU code. 


10.6.3 Structures Maintained by lOU. 

The file management table areas (FMTs) are memory resident 
segments, the number and size of which are defined during sysgen. 
The FMT Is used primarily for In memory representation of files 
currently In use. One may monitor the usage of the FMT by using 
the Execute Performance Display (XPD) command. If the system Is 
approaching maximum utilization, the error message INSUFFICIENT 
FILE MANAGEMENT TABLE AREA AVAILABLE will be Issued. In any 
case. If it Is determined that more table area Is needed, the 
Modify System Table (MST) command may be issued to increase the 
FMT size up to 256K bytes. 
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The following structures are built by or used by lOU, and they 
are found in several different areas, as noted in the 
descriptions. Detailed descriptions of the structures are shown 
In the section on data structure pictures. 

* Directory overhead record (DOR) - Disk structure that 
shows the number of files In a directory, the number of 
available entries, the number of temporary files, and 
several other pieces of miscellaneous directory data. 

* File descriptor record (FDR) - Disk directory record 
that describes the name, location, and characteristics 
of a disk file and the ID of the user who created the 
file. 

* Allas descriptor record (ADR) - Disk structure that 
contains an alternate pathname component for some file 
pathname and points to the FDR for which this name is an 
alias . 

* Key descriptor record (KDR) - Disk structure that 
describes the keys of a key indexed file; a KDR for a 
multifile KIF set contains additional fields to detect 
illegal attempts to combine files. 

* Channel descriptor record (CDR) - Disk directory record 
that describes the name and characteristics of an IPC 
channel. The CDR is located in the directory containing 
the FDR of the program file that contains the channel 
owner task, and it contains the record number of that 
FDR. 

* File structure common (FSC) - Template to define the FDB 
and FCB variants. 

* File directory block (FDB) - A single node of the in- 

memory directory tree structure located in the file 
management table areas. Provides tree linkage and the 
information required to perform direct disk I/O to a 
directory. An FDB is created for each pathname 

component on an assign or attach operation. The FDB is 
a variant of the FSC structure. 

* File control block (FCB) - In-raemory equivalent of the 

FDR, located in the file management table area. The FCB 

is built for only the last component of a file pathname. 

The FCB points to its corresponding FDB. The FCB is a 
variant of the FSC structure. 

* Resource ownership block (ROB) “ The ROB represents a 

job's ownership of a file resulting from an Attach 
Resource operation. The ROB points to an FCB. ROBs are 
always built in the JCA and are chained in a list 
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anchored by JITROB. 

* Channel control block (CCB) - In-memory equivalent of a 
CDR, built on an Assign LUNO to an IPC channel. CCBs 
contain a pointer to the File Descriptor Packet (FDP) of 
the program file containing the channel owner task and 
the eight-character name of the last component of the 
channel pathname. CCBs for global channels are built In 
the STA, and are anchored from CCBSTR In NFPTR. CCBs 
for job-local and task-local channels are chained In a 
single list anchored from JITCCB In the JCA. The CCB 
points to the JSB and TSB of the owner task. 

* Logical device table (LDT) - The LDT Includes a 
description of an I/O resource, usage flags, ownership 
Information, and file rights. Job-local and task-local 
LDTs are built In the JCA and are anchored from JITLDT 
and TSBLDT, respectively. Global LDTs are built In the 
STA and are anchored from LDTLST In NFPTR. LDTRLK 
points to a CCB, FCB, or PDT, depending on the LUNO 
ass Ignment . 

* Resource privilege block (RPB) - The RPB Is a structure 
used to control access privileges for resources. The 
RPB Is built on each Assign LUNO to a device, file, or 
IPC channel. The RPB contains the open access privilege 
flags (2 bits), the address of Its associated LDT, and 
the JSB address of the job that assigned the LUNO (the 
JSB field Is zero for global LUNOS). An RPB for a 
device Is chained to the PDT, an RPB for a channel Is 
linked to the CCB, and an RPB for file Is chained to the 
FCB. The RPB contains currency Information for LUNOs 
assigned to files. 

10.6.3.1 Directory Tree Construction. 

In DNOS, an FDB Is built In the file management table area for 
each component of a file pathname, and an FCB Is built there for 
the last component of the pathname - 

Each disk PDT extension for a file contains the address of the 
VCATALOG FDB and the SSB address of the file management table 
area In which It resides. The VCATALOG entry Is placed there by 
IPL for all devices which are on line during IPL. They are 
placed there by Install Volume (IV) otherwise. lOU maps this 
area Into Its second segment to begin the tree search. Each 
pointer to a node of the tree contains the SSB address of the 
file management table area where that node resides. Since each 
FDB could potentially reside In a different table area, lOU must 
be sure that it has the correct segment mapped In before 
following an FDB pointer. 
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When a new node Is to be added to the tree, an attempt Is made to 
allocate It In the same table area as Its parent. If no space 
remains, other file management table areas are checked. If any 
exist. FMSTR In NFPTR contains the SSB address of the first file 
management table area, and FMEND contains the SSB address of the 
last. The SSBs for the table areas are chained together. lOU 
maps In each successive table area and attempts to obtain space 
for the FDB . The requester Is given an error If no table space 
Is available. When linking a new FDB Into the tree, lOU must be 
sure It has the correct table mapped In when changing parent and 
sibling FDB linkages. 

For files to which global LUNOs are assigned, the LDT Is built In 
the STA. 


10.6.3.2 LDT Structure. 

The LDT Is composed of two parts built by lOU when a LUNO Is 
assigned to an I/O resource. These parts are the LDT and an RPB. 
The LDT Is linked Into the LDT chain. The RPB for a file Is 
allocated In the same segment as the FDB of the corresponding 
node. It Is Impractical to chain together all LDTs assigned to a 
file because the LDTs may be distributed to various JCAs. The 
RPB chain Is the chain that can be traversed to find all users of 
a given resource* Figure 10-13 shows typical LDT chains for a 
task that Is associated with a station and a task that Is not 
associated with a station. 

When a LUNO Is opened, lOPREP searches the RPB chain to check for 
access privilege conflicts. Each RPB contains a two-bit field 
representing Its access privileges and a flag Indicating an open 
LUNO. A privilege conflict could occur with other open LUNOs. 
If no conflicts arise, the access privileges are recorded In the 
RPB and It Is marked open. 

The RPB contains currency Information (Including the current file 
Index set up by file management for concatenated files). 
Currency for any LUNOs assigned to a file may be updated by File 
Management as necessary by updating the currency In the RPB. 
(Note that this Is not the same as the KIF currency Information.) 

Parameters may be Included In the parameter field of an lOU 
operation. The following parameters may be Included , organl zed 
In the subllsts shown. See the format of parameters described In 
the Name Management paragraph In the section on Special SVCs. 
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Subll St 

Parame ter 

Parame ter 

Type 

Numbe r 

Description 


00 

03 

Job access level 


04 

File type 


05 

Job local temporary file 


06 

Initial file allocation 


07 

Secondary allocation 


08 

Logical record length 


09 

Physical record length 


OD 

Expandable 


OE 

Forced write 


OF 

Blank suppressed 


10 

Max # of tasks 


11 

Max # of procedures 


12 

Max # of overlays 


14 

Max // of directory entries 


15 

Default physical record size 


16 

KIF definition block 

02 

— 

User ID parameter (see UIP template) 

04 

— 

Modify file name security option 

05 

— 

Continue LAN session on release Luno 


Each of the parameters Is optional and may or may not have been 
specified by the user. If a system parameter Is chosen (those 
with a subllst # of 0), the parameter overrides what Is given In 
the call block. System parameters are used to communicate 
Information between NAMMGR and lOU. They are not Intended for 
general use. Parameters 2, 4 and 5 are described In more detail 
In the SVC manual . 
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Figure 10-11 LDT Chains 


2270512-9701 


10-63 


1/ 0 Subsystem 



DNOS System Design Document 


10.6.4 Details of lOU Processing. 

lOU processing occurs In a number of modules. Those described 
here Include the preprocessor, lUPREP, the lOU task, and a number 
of modules that support special functions. 

10.6.4.1 lOU Preprocessor (lUI^REP). 

lUPREP runs In map file 0 as XOP-level code. The call block is 
buffered according to the format required by each subopcode. lOU 
processes the following subopcodes. (Starred codes are NOT 
documented In user manuals; they are to be used only by operating 
system tasks . ) 

90 Create File 

91 Assign LUNO to Pathname 

92 Delete File 

93 Release LUNO from Pathname 

* 94 Assign Diagnostic Device 

95 Rename File (Assign New Filename) 

96 Unprotect File 

97 Write Protect File 

98 Delete Protect File 

99 Verify Pathname 

9A Add Allas 

9B Delete Allas 

9C Define Forced Write Mode 

9D Create IPC Channel 

9E Delete IPC Channel 

* AO Attach Resource 

* A1 Detach Resource 

* A3 Detach Resource by Number 

* A4 Modify FDR Bit 

* A5 Release LUNO In Another Job 

* A6 Assign System LUNO FF 

* A7 Release File Structures 


* Not documented to users. 

Pathname characters must be In the following ranges to allow for 
International character support by DNOS: 

>24, >28, >29, >2E, >30 through >39, >41 through >5A, 

>61 through >7A (standard English pathnames) 

>5B through >5D (European characters) 

>A6 through >DF (Katakana characters) 

Pathname length Is checked for all subopcodes that have a 
pathname. If the length Is zero or Is greater than 48, error 
code >92 (Bad Pathname Syntax) is set In the user call block, and 
an exit Is made to RPRTNE In RPROOT. 
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The module lUVRFY Is used to verify pathname syntax. It can be 
linked with any code that performs pathname verification. When 
the routine is called, register 1 must have the address of the 
buffer containing the pathname. The buffer has the length of the 
pathname In its first byte. Register 10 must be a seven word 
buffer to be used as a stack by lUVRFY. Register 0 will be 
modified by lUVRFY, but no other registers of the calling code 
will be modified. If the pathname is correct in syntax, register 
0 receives a value >0000. If the pathname is incorrect, register 
0 receives >9200. 

There are two entry points in lUVRFY. lUVPND is used if the 
pathname can contain both upper and lower case letters, numerals, 
the dollar sign, periods, left and right parentheses around the 
last pathname element, and the pound sign(#). The katakana 
character set and special European characters are also permitted. 
The entry point lUVLET is used if the pound sign is not permitted 
in the pathname. Entry to the routine is via a branch and link 
(BL) to lUVPND or lUVLET, with a data word following the BL 
instruction containing the return address for error conditions. 

The lOU preprocessor defines an RDB that specifies the buffering 
of the standard lOU call block. lUPREP builds RDB expansions 
dynamically to specify additional buffering as follows: 

* If the subopcode requires a pathname, it is set up to be 
buffered in the STA along with the call block, with the 
pathname pointer placed in the BRB. 

* A flag in IRBFLG indicates whether the IRB parameter 
pointer is valid on Assign LUNO operations. If it is 
valid, the parameter list is buffered into the caller's 
JCA and the parameter pointer is set in the BRB. The 
use of parameters on Assign LUNO is for the operating 
system only and is not documented in user manuals. 

* If the utility flags specify KI F , either of the 

following may apply: 

- If the subopcode is >91 (Assign Luno) and either 
the temporary file bit or the autocreate bit is 
set, buffer the keys to the STA and set a pointer 
in the BRB. 

- If the subopcode is >90 (Create File), buffer the 
keys to the STA and set a pointer in the BRB. 

A call is issued to the request processor buffering routine, 
RPBUF , to perform the buffering as defined by the RDB and RDB 
expansion definitions. 

BRBs for all subopcodes that have pathnames are placed on the 
Name Manager queue, unless the first character of the pathname is 
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a period. In the last case, the BRB Is placed directly on the 
queue for the lOU task. 

Name Manager checks to see If the access name Is a logical name. 
If so, the true pathname(s) are buffered Into the STA, and the 
buffered pathname pointer Is reset. Name Manager may add 
parameters to the IRB. 

If parameters exist on an Assign LUNO, they are buffered Into the 
STA, the IRB parameter pointer Is set, and the IRB flag Is set 
Indicating that the parameter pointer Is valid. 

10.6.4.2 Initial Processing In the lOU Task. 

If the IRB flag Indicates that the parameter pointer Is valid, 
lUPRM Is called to process the parameter list. 

lUPRM Is a table-driven module. Each parameter has an associated 
parameter ID. The parameter ID Is used as an Index Into the 
table of subroutine entry points. Each subroutine translates a 
parameter from Name Manager format to the call block format and 
places the pa r ame ter In the correct position of the call block. 
(See the paragraphs on name management for the format of a 
parameter list.) For parameters that have no place In the IRB, 
the parameter (or Its address) Is saved In the lOU address space 
for later processing. 

10.6.4.3 Channel Operations. 

In a Create Channel operation, the channel pathname must be 
Identical to that of the program file conta 1 nl ng the owner t ask , 
except for the last component. For example, for a program file 
named . DI RECT . PROGFI LE , a valid channel pathname Is 
.DIRECT. CHANNEL. If the SVC call block specifies LUNO 0 as the 
program file LUNO for the owner task, lOU assumes that the owner 
task resides on program file .S$SHARED. The SVC returns an error 
If the owner task Is the owner of an existing channel with 
different scope or If the specified scope Is task local and the 
owner Is already the owner of an existing task-local channel. 

The SVC causes a CDR to be built In the same directory as the FDR 
for the program file# The CDR contains the channel description, 
the Installed ID of the owner task, and the record number of the 
FDR for the program file. The CDR Is similar to an ADR and Is 
linked Into the chain of ADRs (that Is, each CDR or ADR contains 
the record number of the next CDR or ADR). The CDR can be 
protected from an accidental Delete Channel operation. The 
channel access name can be specified In the de 1 e t e -p r o t e c t and 
unprotect I/O operations. When a program file Is deleted. Its 
CDRs and ADRs are also deleted. Only the delete-protect flag for 
the program file Is checked when the program file Is deleted. 
See the section on data structure pictures for details of the ADR 
and CDR . 
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In a Delete Channel operation, the CDR for the specified channel 
name Is deleted. The program file containing the owner task Is 
not affected • 

Channel LDTs have a flag to indicate that they are assigned to a 
channel. The LDT points to the CCB. The LDT shows the default 
resource type and type flags carried in the CCB. Each time a 
LUNO is assigned to a channel, the LUNO count in the CCB Is 
incremented. The count is decremented as LUNGS are released, and 
the CCB is deleted when the count equals zero. 

lOU cannot distinguish an Assign to a channel from an Assign to a 
file until the CDR is read. After it is read, an FDB and FCB are 
created for the program file of the owner task. The Assign 
causes the creation of the CCB and the bidding of the owner task 
(unless the relevant structures already exist). The CCB contains 
the eight-character name of the last pathname component for the 
channel. After an owner task is bid, the run-time ID is used to 
search the TSB list for the TSB address of the owner task. The 
calling job JSB address and owner task TSB address are placed in 
the CCB. Each CCB created by an Assign points to an FDP of the 
program file containing the owner task. To search for an 
existing CCB, lOU searches for a CCB with an FMT ,FCB pair that 
matches the desired program file FMT, FCB pair. This indicates 
that the owner task came from the same program file. The 
Installed ID of the owner task must match that of the owner task 
of the channel to which the caller is assigning; a match on the 
last pathname component for the channel is also required. 

To establish a global channel, the owner task must be running and 
issue an Assign to the channel. The CCB is built in the STA, and 
subsequent Assigns to the channel cause the creation of LDTs that 
point to this same CCB. Any requester Assigns that precede the 
owner's Assign will receive errors. The owner of a global 
channel is identified by its installed ID and the value for 
TSBFMT and TSBFCB, the description of the program file from which 
the task was bid. 

The first Assign to a job-local channel causes a CCB to be built 
in the caller's JCA. The owner task is bid by lOU in the 
caller's job via the SVC option that allows a task to be bid in a 
different job. Subsequent Assigns to the same channel use the 
same CCB and owner task. 

For task-local channels, a CCB is created and an owner task Is 
bid on each Assign to the channel (excluding Assigns by the owner 
task). lOU must match up the owner task's Assign with the 
correct CCB, which was previously created. An error is returned 
if the owner is the first to assign to a task-local channel. 

During initial lOU processing of an Assign to a channel for which 
the owner processes Assigns, an LDT flag is set to indicate that 
the LDT is nonusable. The address of the LDT is placed in the 
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BRO , and a BRO flag is set to Indicate that lOU has partially 
processed this request. IRBSID (session ID) is cleared. An 
NFMAPO call Is Issued to the IPC pre-processor to transmit the 
BRB to the owner task. Parameters associated with this call are 
passed to the owner task along with the call block. 

After the owner task processes the Assign, IPC returns the BRB to 
the lOU queue. The BRO flag tells lOU that the request has 
already been processed. The LDT address Is obtained from the 
BRO. If the IRB error code Is nonzero, the CCB LUNO count Is 
decremented, and the LDT Is released. If no error occurred, the 
LDT is completed. The resource type Is placed in the LDT, and 
the nonusable flag In the LDT Is cleared. 

The LDT Is built before the owner processes the Assign because 
the number being assigned must be checked for conflicts before 
owner task processing. In addition, while the owner Is 
processing the Assign, It must be ensured that no other task 
assigns the same job-local or global LUNO. 

10.6.4.4 Concatenated Files and Multifile Sets. 

FCBs for concatenated files are linked together via pointers In 
the FCBs. The FCBs are flagged as being members of a 
concatenation, and the first FCB of the set contains the number 
of files In the concatenation. Concatenated files may be shared 
as a set. lOU provides error checking to prevent concurrent use 
of Individual files of a set. This provides protection against 
unanticipated changes In the structure of the concatenated file 
set. (For example, this prevents another task from changing the 
end-of-me di urn on the second of three concatenated files.) 

A zero In the first byte of the pathname Indicates that multiple 
pathnames are present. The second byte contains the number of 
pathnames. Only Name Manager can provide a pathname In this 
format, because the lOU preprocessor disallows a zero-length 
pathname. The Name Manager generates a pathname when processing 
a logical name for the concatenated file. 

lOU builds an FCB for each file of a concatenated set. An error 
Is returned If the files are special usage files or if not all of 
the files are of the same file type. If LUNOS are assigned to 
any of the individual files, an error Is returned. The FCBs are 
flagged and linked, and the number of files Is placed In the 
first FCB. An RPB Is built and linked to the first FCB. Access 
privileges for concatenated files apply to the set of files, not 
to each Individual file. Open processing checks access 
privileges for the set of files by searching the RPB chain for 
the first FCB only. 

On an attempt to share a concatenated set, lOU provides error 
checking. lOU checks to see that the same number of files Is 
specified, and that the requested flies are In the same order as 
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those already concatenated. An error is returned if these 
conditions do not hold. Each usage of the concatenated set 
causes the creation of an RPB chained to the first FCB. When the 
concatenated set is no longer in use (when the last RPB is 
deleted), all FCBs in the set are released. 

When key Indexed files are combined, they are not considered to 
be concatenated, but are called a multifile set. This is because 
after files are concatenated, they can still be used as 
individual files. This is not true for key Indexed files; once a 
set of files has been combined into a multifile KIF set, they 
cannot be handled separately using KIF operations. 

Multifile KIF sets require special handling. lOU uses the FDR 
end-of -medium field to determine whether a key Indexed file is 
empty. If all the specified files being combined are empty, and 
are not members of an existing multifile set, lOU formats them as 
a single file. The creation date and time of the first file are 
placed in the KDR of each file in the set. Each file is given a 
sequence number, which is an integer value that ranges from one 
to the number of files being combined. The sequence number of 
each file is also stored in the KDR of the file. The KDR for the 
first file contains the total number of files in this set. 

Error checking is provided when nonempty key Indexed files are 
combined. Each KDR must contain the same creation date and time. 
Also, the total number of files from the KDR must be the same as 
the number of files specified in the current combination request. 
The sequence numbers of the files must start at one and continue 
sequentially up to the total number indicated in the first KDR. 
If any of the above conditions is not met, an error is returned. 
An empty key Indexed file may be used as the last (and ONLY the 
last) file of a nonempty multifile set. The new file must not be 
a member of an existing multifile set. The new file is formatted 
and given a sequence number and a time and date to match the 
other file(s). The file count in the first KDR is Incremented. 

When a LUNO is assigned to a single key indexed file, the KDR is 
checked for a sequence number. If one is present, a flag is set 
in the FCB to indicate that the file can be opened only for 
unblocked I/O. This is the mode used by the directory utilities, 
for example. 

10.6.4.5 Temporary Files. 

DNOS supports two types of temporary files; task and job local. 
Task temporary files are created either by using the temporary 
file bit in the Create File operation, or by issuing an Assign 
LUNO with the temporary file bit set. When the Create File is 
used, a standard file name can be specified; when an Assign LUNO 
is used, a name is created in the form #n , where n is a 7-dlgit 
integer. Task temporary files are often used as scratch files by 
system utilities. They are deleted when the last LUNO assigned 
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to the file is released. 

Job temporary files are created by specifying the temporary 
option on an Assign Logical Name operation. The job temporary 
file is created when an Assign LUNO is done to the logical name 
or when a Create File specifies the logical name. The access 
name associated with the logical name is the disk or volume name 
on which the file is to be created. 

lOU creates job temporary files under VCATALOG, and it sets the 
temporary flag in the FDR. After the file is created, lOU 
automatically attaches the resource to the job. The file is not 
detached until the job terminates or the logical name is 
released. The file is deleted when the count of attaches and 
LUNOs assigned in the FCB is zero. 

After a job temporary file is created, the file name must be 
entered in the Name Manager data base. For job temporary files, 
the Name Manager allocates 18 bytes for the pathname (enough for 
the length, e i gh t -char a c t e r volume name, period, and eight- 
character file name). The actual length of the disk or volume 
name is in the first byte of the pathname buffer. lOU places the 
length and file name of the newly created file in the buffer. 
The already-processed flag is set in the BRO , and the BRB is 
placed on the Name Manager's queue. Name Manager is responsible 
for calling the routine to queue the BRB for unbufferlng. 


10.6.5 Operating System Support SVCs. 

lOU provides SVC support for several subopcodes that are not 
available to the general user community. These codes, described 
in detail in the section on special SVC support. Include the 
following: 

Subopcode Purpose 


94 

Assign 

Diagnostic Device 

AO 

At t a ch 

Re s ou r ce 


A1 

Detach 

Re s our ce 


A3 

Detach 

Resource 

by Number 

A4 

Mod 1 f y 

FDR Bit 


A5 

Release 

LUNO in 

Another Job 


10.7 DEVICE I/O UTILITY (DIOU) 


Device utility functions (bidding tasks from a device; changing 
device state; disarming hard break at a terminal; allowing 8-blt 
characters) are performed by Issuing device utility operations. 
These operations are lOU subopcodes and are transportable through 
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IPC. Since none of these subopcodes conflict with other lOU 
subopcodes, they are processed by the DIOU task to get 
concurrency. Some of the subopcodes require software privilege. 
The operations and their subopcodes are: 

Subopcode Purpose 


C2 Get Selected Device Parameters 

C3 Set Selected Device Parameters 

C6 Get CDE From CDT 

C7 Process Device Task Bid 


10.7.1 DIOU Functions. 

All I/O subopcodes are passed by the SVC request processor RPROOT 
to lOPREP, the I/O preprocessor. lOPREP hands all I/O subopcodes 
greater than >90 to lUPREP. lUPREP verifies that DIOU subopcodes 
are In the proper range. lUPREP buffers the parameter field (If 
specified) along with the call block In system table area. 
Control Is then transferred to to DUMAIN for specific subopcode 
processing. 

DSRs bid tasks by calling lOFCDT. lOFCDT places the bid 
character In the PDT and then places the PDT on the BIDREQ queue. 
When the scheduler finds something on the BIDREQ queue. It 
activates lOTBID. lOTBiD gets the device number and bid 
character from the PDT and places them In a Process Device Task 
Bid (>C7) call block. The PDT Is removed from the BIDREQ queue, 
the bid character Is cleared In the PDT, and the call Is Issued 
to DIOU. 

When the CDFPEA flag Is set to 1, DIOU passes the bid character 
In the first byte of the first parameter and leaves the second 
byte 0. The device number Is placed In the second parameter. 
Logon tasks that need to CDE can then perform a Get CDE from CDT 
operation (>C6). If the task Is to be bid In the same job as 
PDTJOB, the CDE parameters are placed In the >2B call block 
parameter fields CDEPVl and CDEPV2. 


10.7.2 DIOU Data Base. 

There Is one data file for each operating system generated. The 
file Is In the directory S$CDT under VCATALOG. The file within 
S$CDT has the same name as the system to which It Is associated. 
Each file has 25 CDTs. The file Is Initialized by the Modify 
Command Definition Table (MCDT) command using SCI, or by DIOU 
during IPL If It does not exist. 
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Each record of the CDT file Is a command definition table (CDT). 
Each record contains the SCI command definition entry (CDE) and 
hard break CDE, the DXP CDE, and 13 zeroed CDEs. That is, each 
CDT has a maximum of 16 CDEs. The last four characters of the 
CDT contains the characters CDT. 

Each time a system Is loaded, DIOU runs the PDT list and places 
device numbers Into the PDTs . 

Each device has a three-byte field In Its PDT to represent the 
CDEs that apply to It. One byte Indicates the CDT to use and a 
word represents the CDEs In the table that are valid for the 
device. If the first bit is on In the word, the first CDE will 
be valid for the device; second bit, second CDE; and so on. This 
way each device may have an unique set of CDEs, with a maximum of 
sixteen. 


10.7.3 Data Structures Used by DIOU. 

System data structures used by DIOU Include the PDT and a 
template of parameters. Relevant fields In the PDT Include 

* PDTNAM - an eight-byte device name field 

* PDTNUM - a two-byte device number 

* PDTCHR - a one-byte field for the bid character set by 
lOFCDT 

* PDTCDT - a one-byte CDT number 

* PDTCDE - the CDE mask for this device's CDT 

The structure template for device parameters (DPR) Is a set of 
equates, one for each field In the DIOU data base (multiple flags 
are stored In one field). Any not marked as read only require 
either software privilege, hardware privilege or system task 
status to modify. 
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UNL 


* * 

* DUTIL DEVICE PARAMETERS (DPR) 03/11/83 * 

* * 

* CHANGES TO THIS TEMPLATE REQUIRE CORRESPONDING * 

* CHANGES TO THE PASCAL TEMPLATE "DPRPAS". * 


*********************************************************** 

* THE DPR TEMPLATE DESCRIBES THE DEVICE PARAMETERS MANAGED 

* BY THE DEVICE I/O UTILITY (DUTIL). IT INCLUDES PARAMETERS 

* IN THE FOLLOWING RANGES: 

* 


* 

* 

PARAMETER 

RANGE 

parameter usage 


* 

>01 - 

>5F 


OPERATING SYSTEM RESERVED 


* 

* 

>60 - 

>FF 


NOT SUPPORTED 


* IN ' 

THE 

FIELD 

COMMENTS 

, RO INDICATES THAT A PARAMETER 

IS 

* READ ONLY AND 

* 

CANNOT 

BE MODIFIED. 


* SPECIAL 

FIELD 

COMMENT 

S: 


* DPRNAM ■ 

- ONE 

TO 

EIGHT 

ALPHANUMERIC CHARACTERS WITH A 

LETTER 

* 


AS THE 

FIRST 

character. 


* DPRNUM • 

- ONE 

WORD NUMBER BETWEEN >0001 AND >07FF, EXCLUDING 

* 


100 

THROUGH 

255 064 THROUGH >FF) . 


* DPRTYP ■ 

- LIKE 

THE PDTTYP FIELD. ON AN ASSIGN LUNO , 

THE VALUE 

* 


OF THIS 

FIELD IS PUT INTO THE LDTTYP FIELD 

OF THE 

* 


LDT 

AND 

IS RETURNED TO THE CALL BLOCK IN THE UPPER 

* 


BYTE 

OF 

THE 

DATA BUFFER FIELD. 


* DPRJOB ■ 

•ie 

- JSB 

OF 

THE FIRST JOB TO ASSIGN A LUNO TO A 

TERMINAL. 

DPRNAM 

EQU 

>01 


RO 

*DEVICE NAME 


DPRNUM 

EQU 

>02 


RO 

*DEVICE NUMBER 


DPRFLG 

EQU 

>03 



*WORD OF FLAGS 


DPRDSF 

EQU 

>04 



*DEVICE STATUS 


DPRTYP 

EQU 

>05 


RO 

^DEVICE TYPE 


DPRJOB 

EQU 

>06 


RO 

*OWNER JOB 


DPRRPB 

EQU 

>07 


RO 

*RPB LIST HEADER 


DPRLC 

EQU 

>08 


RO 

*LUNO COUNT 


DPRCDT 

EQU 

>09 



*CDT NUMBER 


DPRCDE 

EQU 

>0A 



*CDE MASK 


DPRPDT 

EQU 

>0B 


RO 

*PDT ADDRESS 


DPRDTF 

EQU 

>0C 


RO 

^DEVICE TYPE FLAGS 


DPRSTK 

EQU 

>0D 



^SECTORS PER TRACK 


DPROHD 

EQU 

>0E 



*OVERHEAD PER RECORD 


DPRWTK 

EQU 

>0F 



*WORDS PER TRACK 


DPRDRS 

EQU 

>10 



*DEFAULT PHYSICAL RECORD SIZE 


DPRFMS 

EQU 

>11 



*VCAT FD SPECIAL AREA SSB ADDRESS 

DPRFDB 

EQU 

>12 



*VCATALOG FDB ADDRESS 


DPRTFL 

EQU 

>13 



*TEMPORARY FILE NAME SEED 


DPRECT 

EQU 

>14 



*RETRY COUNT 


DPRVNM 

EQU 

>15 



*VOLUME NAME 


DPRCHR 

EQU 

>16 



*BID CHARACTER 
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DPRBLN 

EQU 

>17 


*BUFFER LEN OR # VIRT TERMINALS 

DPRMAX 

EQU 

>18 


* THE LIMIT FOR CURRENT 

OS FARMS 

DPROSM 

EQU 

>5F 


*MAXIMUM O.S. PARAMETER 


* EQUATES FOR DPRFLG 



DPI IRB 

EQU 

0 

RO 

*COPY IRB TO SYSTEM LOG 


DP IRSl 

EQU 

1 

RO 

*RESERVED 


DP1RS2 

EQU 

2 

RO 

*RESERVED 


DPI STA 

EQU 

3 


* DEVICE STATE 


* 

00 - 

ONLINE 




* 

01 - 

OFFLINE 




* 

10 - 

DIAGNOSTIC 




1 1 - 

SPOOLER 




DPIOPF 

EQU 

5 

RO 

*OPEN FAILED 


* EQUATE FOR 

. DPRDSF 




DP2RS1 

EQU 

0 

RO 

*RESERVED 


DP2AID 

EQU 

1 

RO 

*ALTERNATE PDT 


DP2BI 

EQU 

2 

RO 

^BUFFER INPUT 


DP2BO 

EQU 

3 

RO 

*BUFFER OUTPUT 


DP2 JIS 

EQU 

4 


*JISCII, 8-BIT ASCII MODE 

DP2REN 

EQU 

5 

RO 

*RE ENTER ME 


DP2 JAR 

EQU 

6 

RO 

*JISCII RECEIVE 


DP2 JAT 

EQU 

7 

RO 

*JISCII TRANSMIT 


DP2RS2 

EQU 

8 

RO 

*RESERVED 


DP2RS3 

EQU 

9 

RO 

*RESERVED 


DP2WPM 

EQU 

>A 

RO 

*WORD PROCESSING MODE 


DP2 IRE 

EQU 

>B 

RO 

*INITIAL REQUEST 


DP2INT 

EQU 

>C 

RO 

*DEVICE INTERRUPT LEVEL 

MASK 

* EQAUTES FOR DPRDTF 

' - 

DEVICE TYPE FLAGS 


DP3FIL 

EQU 

0 

RO 

*FILE ORIENTED 


DP3TIL 

EQU 

1 

RO 

*TILINE DEVICE 


DP3TIM 

EQU 

2 

RO 

^ENABLE TIME-OUT 


DP3PRI 

EQU 

3 

RO 

*PRIVILEDGED DEVICE 


DP3KSB 

EQU 

4 

RO 

*TERMINAL WITH A KSB 


DP3COM 

EQU 

5 

RO 

*COMM DEVICE 


DP3SYD 

EQU 

6 

RO 

*SYSTEM DISC 


SP3RES 

EQU 

7 

RO 

*RESERVED 



LIST 





DPRNAM 






One to 

eight 

alphanumeric characters with 

a letter as the 

first character 

• 



DPRNUM 






A 

one word number 

between >0001 and >07FF 

excluding 100 

through 

255 . 




DPRFLG 






DPRFLG 

is a f 1 a 

g word with the following bit 

definitions . 
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DPI IRB 

= 

(X 

) 

- COPY 

IRB TO SYSTEM LOG 

DPIRSI 

= 

( .X 

) 

- RO 

RESERVED 

DP1RS2 

= 

( . .X 

) 

- RO 

RESERVED 

DPI STA 

= 

( . . .XX 

) 

- DEVICE STATE 





00 - 

ONLINE 





01 - 

OFFLINE 





10 - 

DIAGNOSTIC 





11 - 

SPOOLER 

DPI OPF 

= 

( 

> » . • X . . ) 

- OPEN 

FAILED 

DPI RS3 

= 

( 

XX ) 

- RO 


DPRDSF 






DSPDSF is 


a flag word 

with the 

following bit definitions. 

DP2RS1 

= 

•••• 

• • • • • • • 

. ) RO 

RESERVED 

DP2AID 

= 

(.X.. .... 

• • • # • • • 

. ) RO 

ALTERNATE PDT 

DP2BI 

= 

(..X. .... 

♦ • • • • • • 

. ) RO 

BUFFER INPUT 

DP2B0 

= 

(...X .... 

• • • • • # • 

. ) RO 

BUFFER OUTPUT 

DP2 JIS 

= 

(•••• 

• • • • • • ♦ 

. ) RO 

JISCII, 8-BIT ASCII MODE 

DP2REN 

= 

(...• .x.. 

• • • • • # # 

. ) RO 

RE ENTER ME 

DP2 JAR 

= 

(...• ..x. 

• • • • # • • 

.) RO 

JISCII RECEIVE 

DP2 JAT 

= 

(.... ...X 

• • • • ♦ # • 

. ) RO 

JISCII TRANSMIT 

DP2RS2 

= 

(•••• •••• 

X . . « ... 

. ) RO 

RESERVED 

DP2RS3 

= 

(•••• •••• 

. X . . ... 

. ) RO 

RESERVED 

DP2WPM 

= 

(•••• •••• 

• . X . ... 

. ) RO 

WORD PROCESSING MODE 

DP2 IRE 

= 

(.... .... 

... X ... 

. ) RO 

INITIAL REQUEST 

DP2INT 

= 

(.... .... 

.... XXXX) RO 

DEVICE INTERRUPT LEVEL MASK 


DPRTYP 

The DPRTYP field corresponds to the PDTTYP field. On an 
Assign LUNO, the value of this field is placed in the LDTTYP 
field of the LDT as well as being returned in the upper byte 
of the data buffer field of the Assign LUNO call block, 

DPRJOB 

DPRJOB is the same as PDTJOB, It is only valid for devices 
with a KSB (terminals). The JSB of the first JOB to assign 
a LUNO to terminal is placed in DPRJOB, This prevents any 
other JOB from assigning a LUNO to the terminal. 

DPRRPB 

DPRRPB is the same as PDTRPB. For devices that validate 
opens an RPB must be generated during assign LUNO 
processing. DPRRPB contains the address of the beginning of 
the RPB list. 

DPRLC 

DPRLC is the same as PDTLC, This field contains a count of 
the number of LUNOs assigned to the device. 

DPRCDT 

The first byte of DPRCDT identifies the CDT for this 
terminal. The next two bytes are the word mask that 
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identifies the CDEs within the CDT that are valid for this 
terminal . 


10.8 FILE ACCESS SECURITY 

DNOS 1.2 Includes security on a per file basis. Directory 
security and volume security are not Implemented In this release. 

A user's security environment is defined at the job level. 
Associated with each job in the system Is a user ID and the list 
of access groups of which he Is a member. A collection of users 
which are expected to have similar access to files belong to an 
access group. All secured files have a list of access groups and 
rights which determine who may access the file and In what 
manner. This list Is called an access control list. Permission 
Is granted If the user Is a member of an access group In the 
access control list. 

Since security Is enforced on a per job basis, It Is not possible 
for a server job to accept files from other jobs and perform 
operations on those files with the original user's security. The 
spooler Is an example of such a server job. To solve this 
problem, an option for secured lOU SVCs Is supported. A task can 
specify the user ID with which the access rights for the LDT will 
be generated. Such a task must have the security bypass feature 
and enforce its own security, unless the passcode for the user ID 
Is also specified. Specific operations that have this feature 
Include Assign LUNO, Create File, Delete File, Modify File Name, 
and the Modify File Protection SVCs. 

Assigning a LUNO to the disk (using direct disk I/O) and bidding 
a task In another job are potential security bypass operations 
that are not restricted by the operating system. These are 
better handled through the use of functional security or by 
allowing tasks to be members of access groups, features that may 
be Implemented in a future release. 


10.8.1 Establishing a Job's Security Environment. 

A user's security environment is determined during job creation. 
The logon task solicits a user ID and passcode. If logon Is 
turned off through use of the MTS command, this information Is 
located In the S$SCA file. The user ID and passcode are 
validated against the entries In the S$CLF file. 

Job Manager, during create job processing, validates the user ID 
and passcode against the S$CLF. This check is necessary since 
not all create jobs are issued by the logon task. Job manager 
reads the S$CLF to find the user ID, passcode and access groups. 
The user ID is copied Into the JSB. The encoded passcode Is 
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copied into the JIT. A capability list is built. This list 
Includes a count of access groups followed by a list of encrypted 
access group names, each name followed by a flag word. This list 
resides in the JCA, pointed to by JITCAP. 

The security manager function is performed by an overlay of lOU. 
This overlay is not Included as part of the kernel program file 
if the security option is not chosen during sysgen. In general, 
a user's security access to a file is determined during assign 
LUNO processing. The rights are stored in the LDT. Subsequent 
operations to the file check the rights in the LDT to determine 
whether the user has appropriate access. 

All lOU operations are first processed by lUMAIN. lUMAIN 
maintains a table of secured lOU operations. These operations 
include Create File, Assign LUNO, Delete File, Modify File Name, 
Unprotect File, Write Protect File and Delete Protect File. 
Several conditions must be met before security checking is done: 
the system must be secured, one of the above secured subopcodes 
must have been encountered, and the pathname must be longer than 
a single node (indicating possibly a file as opposed to a 
device) . 

lUSPRE is the security manager preprocessor routine. If a user 
ID parameter is passed with the IRB, lUSPRE verifies that it is 
valid. If the parameter was not specified by a security bypass 
task, the passcode is also verified. A capabilities list is 
generated from the S$CLF file instead of using the capabilities 
list pointed to by JITCAP. 

For all secured suboperations except Create File, lUSPRE calls 
lUGAR to generate the user's access rights to the file. lUGAR 
calls the lOU routines that build the FDB tree and FGB for the 
file. It calls a routine to compare the capabilities list with 
the file's access control list. If the access group in the 
capabilities list is SYSMGR, the user receives total access to 
the file. If no access groups are associated with the job the 
user will receive PUBLIC access to the file. If no access groups 
are found and no PUBLIC rights are specified, the operation will 
fall. The user will be returned a security violation error. If 
some access is determined, control is returned to lUSPRE. 

If the operation is an Assign LUNO, the rights are saved off to 
be later entered into the LDT during the Assign LUNO routines. 
If the operation is a Delete File or a Modify Protection SVC, the 
proper access is verified. In the case of a Modify File Name, 
the access is verified for the new pathname, if it existed. The 
access for the old pathname is verified by looking at the LDT 
rights field. A Modify File Name of a directory is specifically 
not allowed . 

A Modify File Name option exists which allows the user to keep 
the security of the new pathname. If this option is specified. 
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the security Is copied to system table area In a structure known 
as an access control packet. After the Modify File Name takes 
place, the security Is copied from the access control packet to 
the file and the packet Is released. If the option Is not 
chosen, the default results of the Modify File Name leave the 
file secured with the old pathname's access rights. 

If a LUNO Is being assigned to a concatenated file, the 
concatenated file processor calls the security routines to 
determine the access rights for each file. These rights are 
ANDed to determine the final access rights. 

In the case of file creation or Assign LUNO with auto-crea t Ion of 
a file, lUSPRE calls a routine to search the capability list to 
find the creation access group. If no such group Is specified, 
the default Is taken as PUBLIC. When the file Is created, the 
encrypted group name Is written to the FDR with all access right 
flags set, and the public bits are turned off. 

Aliases Inherit the security of the file to which they refer. 
The addition or deletion of aliases Is not secured. 

Minimal channel security Is Implemented. lUSPRE saves the rights 
to the channel owner program file. Before a channel owner Is 
auto bid by an assign LUNO to the channel, the rights are checked 
for execute access. 


10.8.2 Enforcing Security. 

The security manager does some set up of the security environment 
and enforces security for lOU operations. Security Is enforced 
In each process that performs a protected or a particularly 
dangerous function. 

10.8.2.1 File Manager. 

There are differences between open access privileges and security 
rights. The access privileges specified on an Open operation 
enable a user to limit access by others while performing a file 
operation. It may be desirable for a user who has only read 
access rights to a file, for example, to open It with exclusive 
use. That Is, he may only read the file, but while doing so, no 
operation to this file by others may take place. 

File manager enforces read and write security to files. The file 
manager routine lOPREP compares the I/O subopcode against a table 
of allowable operations. The tables and required access are 
given below . 
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File operations allowed only 


if the requestor has read access: 


>09 - 
>0A - 
>41 - 
>42 - 
>44 - 
>45 - 
>48 - 
>59 - 


Read ASCII 
Read Direct 
Read Greater 

Read by Key, Read Current 
Read Greater Than 
Read Next 
Read Previous 
Multiple Record Read 


File operations allowed only if the requestor has write access: 


>02 

>0B 

>0C 

>0D 

>10 

>46 

>47 

>49 

>5B 


Close with EOF 

Write ASCII 

Write Direct 

Write logical EOF 

Rewr i t e 

Insert 

Rewr i t e 

Delete by Key 

Multiple Record Write 


File operations which will succeed if Assign LUNO was successful: 


Open 

Set Currency 

Forward, Backward Space LUNO 
Read File Characteristics 
Unlock 
Close 

Specify Write Mode 
Rewind 


10.8.2.2 Program Manager. 

Program management enforces security on task bids and overlay 
loads. NFTBID checks the program file LDT for execute access 
when bidding tasks. Overlay loads are checked by PMOVYL. Task 
installations, deletions and assigning program space are enforced 
by file manager when the user tries to read or write to the 
program file. S$SHARED is assumed to be a public program file 
and cannot be secured. When LUNO >FF is specified, no security 
check is made since execute access to the program file has 
already been established. 

10.8.2.3 Segment Manager. 

In order to do a Change Segment operation for a program file 
segment, the user must have execute access to the program file. 
In order to do relative record I/O using a Change Segment SVC, 
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the user must have read and write access to the relative record 
file. In order to do relative record I/O using a Create Segment 
SVC, the user must have write access to the relative record file. 
The above is enforced by segment management in SMPREP. 

10.8.2.4 Sy sgen . 

In DNOS 1»1, if the SVC for security was specified the Encrypt 
and Decrypt SVCs were Included. In DNOS 1.2, the ENCRYPTION SVC 
group Includes those SVCs. In DNOS 1.2, a YES response to the 
global SECURITY question causes the system option word security 
bit in NFDATA is to be set, the security overlay for lOU to be 
added to the kernel program file, and the encryption SVC group to 
be Included. 


10.8.3 Volume Security. 

A utility called Modify Volume Security (MVS) is supplied to make 
it Impossible to Install a secured DNOS volume on a DX 1 0 or an 
unsecured DNOS system. It is located in the .S$SECURE program 
file. This task modifies a field in sector zero which indicates 
to the Install volume processor that this can only be installed 
on a secure system. 


10.8.4 Networking. 

For DNOS 1.2, the security access one will receive doing remote 
I/O will be the access of the remote LAN job, as the SVCs are 
Issued remotely by this job. When performing a remote logon, one 
acquires the security associated with the user ID used to log on. 

10.8.4.1 Manipulation of the Access Control List. 

Modifications to the access control list for a file are made by a 
system task called MSAR. This utility task allows a user to 
modify the security access rights of any file for which the user 
has the control access right. It also allows a user to display 
the list of access groups which currently have access to the file 
and what access rights each group has to the file. 

MSAR is bid by the MSAR and LSAR SCI command procedures. The 
FARMS list is as follows: 
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FARM Definition 


1 

Funct ion code : 

0=LSAR; 

1=MSAR 



2 

User's 

passcode 






3 

File pathname 






4 

Listing 

access 

name 

(not 

used 

for 

MSAR) 

5 

Access 

group name 

(not 

used 

for 

LSAR) 

6 

Read 

access 

(YES/NO) 

(not 

used 

for 

LSAR) 

7 

Write 

access 

(YES/NO) 

(not 

used 

for 

LSAR) 

8 

Delete 

access 

(YES/NO) 

(not 

used 

for 

LSAR) 

9 

Execute 

access 

(YES/NO) 

(not 

used 

for 

LSAR) 

10 

Control 

access 

(YES/NO) 

( not 

used 

for 

LSAR) 


The MSAR task consists of the modules MSMAIN, MSMSAR, MSLSAR, 
MSDOOR, MSDDIO, MSFUDR, and MSRCLF from the VOLOBJ.MSAR. OB JECT 
directory, several low level subroutines from the 
VOLOB J , 1 OU . OB JE CT directory, the passcode encryption subroutine 
from the VOLOB J . SECURITY . OB JECT directory, and stardard UTCOMN 
and S $ r OU t Ine s . , 

MSMAIN verifies that the utility is being run on a DNOS 1.2 (or 
later) system. It then assigns and opens a LUNO to .S$CLF, picks 
up the user's ID from the JSB, finds the user descriptor record 
(UDR) within .S$CLF for the user, and verifies the passcode 
entered by the user. If the passcode verifies, MSMAIN then 
assigns a LUNO to the user specified file, finds the LDT for the 
LUNO just assigned, and verifies that the file is a local file, 
not a directory, and that the user has the control access right 
for the file. If all goes well, MSMAIN then calls lUGFCB to map 
in the FCB for the file and saves the FCB address for later 
direct disk I/O operations. MSMAIN then goes to either MSLSAR or 
MSMSAR depending on the operation specified. 

MSLSAR closes and releases the LUNO to .S$CLF as the utility is 
done with that file. It then calls S$OPNS to open the listing 
file with the security rights of the requesting user ID. This 
special entry point in the S$OPEN routine must be used because 
the MSAR task is Installed with the security bypass attribute, 
but the user must not be allowed to put the listing on top of 
files to which he does not have write access. MSLSAR then calls 
MSRFDR to read the FDR for the user specified file and formats 
the listing to show the various access groups that have access to 
the file and the access rights for each group. 

MSMSAR calls S$PARM to get the user specified access group name. 
If the name is SYSMGR, MSMSAR terminates with an error message. 
Otherwise, MSMSAR verifies that the access group name is valid on 
this system. If the name is PUBLIC, then it is considered valid. 
Otherwise, MSMSAR calls MSRCLF to read records from .S$CLF and 
verifies that the name is a valid existing access group name. At 
this point, MSMSAR closes and releases the LUNO to .S$CLF since 
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the utility is now done with that file. MSMSAR then calls S$PARM 
several times to determine the various access rights which the 
specified for the access group to have. MSMSAR then calls MSDCLO 
to close the door on the directory in which the FDR for the user 
specified file resides, calls MSRFDR to read the FDR for the 
file, changes the access control list appropriately, calls MSWFDR 
to write the FDR back to disk, and then calls MSDOPN to open the 
door for the directory. MSMSAR then releases the LUNO to the 
user specified file and terminates. 


10.9 INTERPROCESS COMMUNICATION (IPC) 

IPC provides the capability for two or more tasks to exchange 
information. The information exchanged may take the form of a 
synchronization signal, a short message, a request for a service, 
or a high-volume data transfer. The distinction between these 
categories is often blurred in practice. 

The primary IPC operations are to read and write messages. The 
task to which a write or read is addressed may be identified in 
several ways. In a message-oriented IPC mechanism, no permanent 
channel exists between the two communicating processes. Writes 
and reads are addressed to specifically named processes, and the 
IPC supervisor must utilize a rendezvous table to resolve 
matching operations. The IPC approach in DNOS is channel 
oriented. Channels are created and exist independently of the 
tasks that use them; IPC requests are directed to the appropriate 
channel s . 

In DNOS, a channel is defined as an IPC path between two 
different tasks within the same computer, with one of the tasks 
designated as the owner of the channel. A channel owner has 
control over how the channel is used, while the second task (the 
requester) has less flexibility and fewer privileges. 

IPC processing in DNOS has the following characteristics: 

* Each write or read operation is addressed to a channel, 
to which a LUNO has been assigned. 

* Each operation Issued to a channel by a requester must 
be matched by an operation of the channel owner. 
Depending on the operation issued and the current 
environment, the requester may or may not be suspended 
until the operation completes. 

* Each channel has a queue of pending requests to the 
owner, ordered chronologically. 

IPC channels may be used via SCI like other I/O resources on a 
DNOS system. Some of the SCI commands available for use with IPC 
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channels are the Create IPC Channel (CIC), Delete IPC Channel 
(Die), and Show Channel Status (SCS) commands. 


10.9.1 IPC SVC Interface. 

All program-level access to the IPC facility is through the DNOS 
SVC mechanism. The general SVC parameter block used for IPC 
service calls to symmetric channels is like that used for 
resource-independent I/O. The SVC parameter block used for 
request SVCs to master-slave channels may be like that used for 
r e sour ce -s pec 1 f 1 c I/O. The parameter block for utility calls Is 
like that used for file and I/O utility calls. The IPC opcodes 
are shared with the DNOS I/O facility, with the operation 
performed depending on the context. 

Every channel has one owner. The owner of a channel Is always 
Involved in every message exchange or other operation on that 
channel . Any user other than the owner of the channel may 
communicate only with the owner. This results from the matching 
rules used by IPC when handling requests to channels. These 
rules are given In the description of the IPC support routine, 
IPCGQR. 


10.9.2 Channel Characteristics. 

DNOS channels can be defined as either symmetric or ma s t e r / s lave . 
Symmetric channels function with simple read and write requests, 
where one correspondent on the channel Issues a read while 
another issues a write. The data written Is passed to the 
reader's buffer when a pair of requests match. In a master/slave 
channel, the master task receives the entire buffered SVC block 
for processing. The master task processes and returns the 
modified request to the requester (slave) task. 

10.9.2.1 Symmetric Channel Activity. 

Symmetric channels are used for communicating messages or data in 
a relatively restricted fashion. Tasks may be written in high- 
level languages or in assembly language to synchronize, exchange 
Information, or facilitate use of common files. The operations 
addressed to the channel by such tasks are limited to Open, 
Close, Close EOF, Read Status, Read, Write, and Write EOF. 

From the point of view of an owner or requester task, a symmetric 
channel is always in one of three states: 

* Closed - The task must issue an Open to use channel. 

* Open - The task may issue any operation that is legal in 
this channel access mode. 
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* Dormant - The task must Issue a Close and then may again 
open and use the channel. 

The transitions between states are shown In Figure 10--14. 

An Open to a channel, when fielded by the I/O preprocessor, Is 
checked against current access privileges held by other 
requesters. The same rules apply for channels as for other I/O 
resources when granting or denying access to any user after the 
first. For example. If one requester opens a channel with 
privileges of exclusive all, no other requester can open the 
channe 1 . 

Most symmetric channel requesters Issue Opens with shared access. 
When the requester wishes to be the only requester served, the 
channel should be created as a non-shared channel. 

IPC uses the access privileges specified on an Open to allow or 
deny particular I/O operations to a symmetric channel. For 
example, a user who opens with read only privileges might Issue a 
Write. That Write Is not allowed (just as It Is not allowed to a 
read-only device like a card reader). 

Although requesters may not be aware of the fact, the channel 
definition may dictate more stringent access privileges than they 
specify. For example, a symmetric channel established as a 
nonshared channel can be opened by a requester in any mode, but 
It will function with only one requester at a time. This Is 
necessary for the read/write channel resource mode of a symmetric 
channel, since the owner task has no way of differentiating 
between requesters. 

A Close may be issued by an owner or a requester, or it may be 
Issued by DNOS when processing an abnormal termination by a task 
on the channel. IPC adjusts the CCB to reflect the Close; the 
I/O postprocessor modifies the LDT as It does for devices. Any 
queued requests from the closing task are removed from CCB 
queues . 

When a Close Is Issued by an owner, IPC fields the request and 
the channel Is marked as dormant for all requesters currently 
open. This setting causes requesters to receive errors on any 
operations except Open and Close. As soon as a requester on a 
dormant channel Issues a Close, the channel Is again closed for 
that requester; however. It Is available to be opened. Opens to 
a dormant channel are queued to the CCB until each Close has been 
processed and the channel owner can again Issue an Open. 

A Read Device Status operation Is queued to IPC for processing as 
soon as the IPC task executes. 
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Figure 10-12 Symmetric Channel States 


On other operations to a symmetric channel , a match must be found 
by IPC before the operation will be performed. That Is, one task 
must Issue a Read and the other a Write before either operation 
will be processed. 
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The owner task may have only one request outstanding to a 
particular channel at any one time. If an owner Issues a request 
to a channel to which an owner request Is already pending, the 
second request will be returned with an error. 

10.9.2.2 Master/Slave Channel Activity. 

A master/slave channel Is established so that an owner task may 
process all requests of the requester tasks. The master/slave 
owner task can be written In assembly language using the Master 
Read, Master Write, Redirect Assign Luno, and Read Call Block 
operations. It may be written In a high-level language with 
subroutine support to Issue these SVCs. 

When accessing a master/slave channel, a requester may need to 
pass a set of parameters to the master (owner) task. These 
parameters may be specified as part of an Assign Logical Name 
command and passed to the owner task via an Assign LUNO 
operation. 

In this and other cases an owner task may process requester 
Assign LUNO and Release LUNO operations, gathering and supplying 
data from and to lOU. This option Is specified by the Create IPC 
Channel SVC operation or SCI command. The owner receives the 
request with Master Read and modifies It to reflect appropriate 
processing. The owner task then Issues a Master Write of the 
Assign LUNO call block. IPC queues the request back to lOU to be 
completed. The owner task must not modify certain fields In the 
SVC block, so that IPC can correctly return the block. 

Similarly, the owner may process Abort I/O SVCs (>0F) or I/O 
utility operations other than Assign LUNO and Release LUNO. 
These options can be specified by the Create IPC Channel SVC 
operation or SCI command. 

While using a master/slave channel, a requester task may Issue 
any I/O operation to a channel, and the owner task processes the 
operation depending on how the owner task Is designed. The owner 
task Issues a Master Read to obtain a request for processing and 
a matching Master Write to return messages or status Information 
to the requester. 

Owners of master-slave channels may have only one request 
outstanding to a particular channel at any one time. The Master 
Write and Redirect Assign LUNO operations are exceptions to this 
rule. An owner may Issue either a Master Write or a Redirect 
Assign LUNO while a Master Read, Read Call Block, or Read Status 
operation Is pending. 

All I/O operations Issued by the requester are passed to the 
owner task by IPC. Figure 10-15 shows the operations used by the 
owner task . 
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10.9.3 Details of IPC Processing. 

Service calls to IPC channels are first routed through the I/O 
preprocessor, lOPREP, for common I/O handling. They are then 
passed on to the IPC preprocessor, IPCPRE. This routine checks 
for some error conditions. If no error Is found, IPCPRE 
determines whether fast transfer Is possible. If fast transfer 
Is possible, the exchange Is performed Immediately. Otherwise, 
the request Is queued to the IPC queue server, IPCTSK, and the 
requester task Is suspended. 

10.9.3.1 Structures Used for IPC Processing. 

Each channel Is represented by a channel control block (CCB) In 
the system table area or the job communication area. The CCB 
contains two queue headers: the pending queue (CCBPBQ) and the 
already-processed queue (CCBABQ). All requests awaiting 
processing by IPC other than Master Write and Redirect Assign 
LUNO requests are placed on the CCBPBQ. Master Write and 
Redirect Assign LUNO requests are placed on the CCBABQ. 
Requester call blocks which have been master read but have not 
yet been master written or redirected are stored on the CCBABQ. 
There Is never more than one owner request on any queue. If 
there is an owner request on a queue. It will always be the first 
entry on the queue. 
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The IPCQUE, which is in the system table area, contains requests 
for task level IPC processing. The queued requests are processed 
by the IPC queue server IPCTSK, The queue entry is a QIR, shown 
in the section on data structure pictures. The queue link field 
is used to chain all current requests to be performed by IPCTSK. 
If the channel being used for this queue entry is global, the JSB 
address (to find the CCB) is zero. This indicates that the CCB 
and BRBs are in the STA. For other types of channels, the JSB is 
used to find the segment information so that the JCA segment can 
be loaded into memory and the CCB and BRBs can be located. 

The anchor for IPCQUE is in the STA. The anchor is a standard 
DNOS queue header, shown by the QHR template in the section on 
data structure pictures. When NFQUEH places an entry on the IPC 
queue, IPCTSK is bid. IPCTSK processes each queue request by 
examining the CCBABQ and CCBPBQ for the CCB specified in the QIR 
and matching as many requests as possible. 


10.9.4 Detailed Operation of IPC Routines. 

There are two paths through the IPC subsystem: a task level path 
and an XOP level (fast transfer) path. All IPC requests are 
handled by the IPC preprocessor, IPCPRE. IPCPRE determines 
whether a request can be handled in fast transfer mode. If so, 
IPCXFR is called to transfer the request to the IPC task (which 
must be in memory). The IPC task, running in XOP mode (map 0) , 
processes the request. The routine IPCXOP in the IPC task 
handles the request. If IPCPRE determines that fast transfer is 
not possible, the request is queued and later processed by the 
IPC queue server, IPCTSK. The same code (IPCPRO, IPCMRD and 
IPCMWT) is used to perform both XOP level and task level IPC 
processing. Fast transfer is only possible when the IPC task and 
all necessary buffer segments are in memory. 

If a channel owner releases its LUNO to the channel, or if the 
owner of a task-local or job-local channel terminates, the 
channel is considered dead. This is indicated by the CCB flag 
CCFDED. lOU or PMTERM will set the CCFDED flag, build a QIR for 
that channel, and queue it to IPCQUE in order to activate IPC. 
IPC will return outstanding and subsequent requester requests 
with an owner aborted error, (error code >A7). 

10.9.4.1 IPC Preprocessor (IPCPRE). 

IPCPRE runs at XOP level when an I/O or lOU call buffered by 
lOPREP or lUPREP is detected as being for a channel or remote 
resource. The following is a description of the IPCPRE 
algorithm; 
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IF the request Is an I/O request or an Abort I/O request 
THEN BEGIN 

IF the request requires a buffer 

THEN call IPCCB to build a Buffer Address Packet (BAP) 
for the buffer . 

IF the channel is not busy and the IPC task is in memory and the 
request is not a Redirect 

THEN BEGIN 

call IPCXFR to process request in fast transfer mode. 

IF IPCXFR returns without error 
THEN return. 

* If IPCXFR returns an error, one of the task 

* segments or buffer segments was not in memory, 

* so fast transfer was not possible. The request 

* hag been queued by IPCXOP to the CCB. All we 

* have to do now is queue a QIR to the end of IPCQUE 
END 

ELSE IF request is a Master Write or Redirect Assign LUNO 
THEN queue request to head of CCBABQ, 

ELSE IF request is an owner request 

THEN queue request to head of CCBPBQ. 

ELSE queue request to end of CCBPBQ. 

END 

generate a Queued IPC Request (QIR). 
queue the QIR to the end of IPCQUE. 
set the Channel Busy flag in the CCB. 
return . 


10.9.4.2 IPC Queue Server (IPCTSK). 

When a request cannot be processed in XOP mode, the request is 
processed at the task level by IPCTSK. IPCTSK is activated by 
NFQUEH when a QIR is queued to IPCQUE. The following is a 
description of the IPCTSK algorithm. 
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WHILE the IPCQUE is not empty 
BEGIN 

get request from IPCQUE. 

IF channel Is job or task local 
THEN map the JCA that contains the CCB 
WHILE there exist processable requests on the 
CCBPBQ or CCBABQ 
BEGIN 

call IPCGQR to get a request or a pair of 
requests. 

IF IPCGQR returned an owner request 
THEN IF the owner request requires a buffer 
THEN load the buffer segment. 

IF IPCGQR returned a requester request 
THEN IF the requester request requires a buffer 
THEN load the buffer segment. 

IF this Is a master/slave channel and the owner 

request Is not a Redirect or a Read Call Block 
THEN load all requester task segments, 
call IPCPRO to execute the data exchange. 

IF owner request was not processed 

THEN requeue the request to the CCB. 

IF requester request was not processed 

THEN requeue the request to the CCB. 
unload any task segments that were loaded. 

END 

reset the Channel Busy flag In the CCB. 

END 


10.9.4.3 IPC XOP level request processor (IPCXOP). 

The routine IPCXOP Is in the IPC task, although It Is only 
executed in map 0. If IPCPRE determines that the IPC task Is In 
memory, a branch and link Is performed to IPCXFR, which transfers 
control to IPCXOP. 

IPCXOP queues the request to the CCB and calls IPCGQR to get a 
request or pair of requests from the CCBABQ or CCBPBQ. The 
subroutine IPCCHK Is called to determine whether the requests 
returned by IPCGQR can be processed in fast transfer mode. If a 
request cannot be processed, either because of an error or 
because fast transfer Is not possible, the request is requeued 
for processing by IPCTSK, 

IPCXOP continues to process requests from the CCBPBQ and CCBABQ 
until a request cannot be processed. 


10.9.4.4 IPC request processors (IPCPRO, IPCMRD and IPCMWT) . 
IPCPRO, IPCMRD, and IPCMWT are the routines In the IPC task that 
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actually perform the data exchange between requests. IPCPRO is 
called by IPCTSK or IPCXOP for all requests. IPCPRO calls IPCMRD 
and IPCMWT to process Master Reads, Master Writes and Redirect 
Assign LUNO operations. Other operations to master/slave 
channels and all operations to symmetric channels are performed 
directly by IPCPRO. 

On a Master Read or Read Call Block, IPCMRD or IPCPRO copies the 
requester's call block into the master task's master read buffer 
(MRB). On a Master Read, the call is dequeued from the CCBPBQ 
and placed on the CCBABQ to await a Master Write or a Redirect 
Assign LUNO. On a Read Call block operation, the requester call 
block is left on the CCBPBQ. On a Master Write, IPCMWT unbuffers 
selected fields of the requester call block from the copy in the 
MRB into the copy buffered in system table area. Assign LUNO and 
Release LUNO call blocks are queued for reprocessing by lOU. End 
of record processing is performed on all other call blocks. 

The initial processing of the Redirect Assign LUNO operation is 
similar to that of a Master Write of an Assign LUNO call block. 
Selected fields of the call block are unbuffered from the MRB 
into the copy of the call block in system table area. Additional 
processing required for Redirect Assign LUNO is as follows: 


1. The LDT that was built by lOU while it was processing 

the requester call block must be deleted. IPC 
accomplishes this by obtaining some table area, 
building a call block for an >A5 I/O operation, and 
queueing it to lOU. An >A5 is a Release Luno in 
Another Job SVC. It is documented in the section on 
special SVCs. The call block must look to lOU as if it 
has already been processed once by lOU (otherwise, lOU 
will note that the channel processes assigns and 
releases and will give the call block back to IPC). 
lOU normally converts an >A5 into a >93 (Release Luno) 
by changing the subopcode to >93, setting the >A5 flag 
(BRFA5) and the Already Seen flag (BRFARS) in the BRO 
flags, and swapping the JSB and TSB in the >A5 call 
block with the BROJSB and BROTSB. IPC must duplicate 
all of these actions. When lOU processes the call 

block, the LDT will be deleted. 

2. The pathname in the MRB must be buffered into the 
requester call block in system table area. IPC does a 
Get Table Area SVC, copies the pathname into the table 
area buffer, and changes the pathname pointer in the 
requester call block (IRBPNA) to point to the new 
pathname. This pathname specifies the channel to which 
the Assign LUNO is to be redirected. The field IRBRPN 
(redirected resolved pathname), which is a null pointer 
for all call blocks that have not been redirected, is 
set to the previous value of IRBPNA. Subsequent 
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redirects of this call block will not alter the IRBRPN 
field. The IRBRPN field points to the resolved 

original pathname. 

3. The Already Seen flag (BRFARS) in the BRO flags is 
reset so that the Assign LUNO call block appears not to 
have been processed by lOU. The call block is then 
queued to Name Manager. Name Manager will queue the 
call block to lOU, and lOU will build a new LDT for 
this Assign LUNO call block. 

4. End of record processing is done on the Redirect Assign 
LUNO call block. 


10.9.4.5 IPC Support Routines. 

IPCEOR 

IPCEOR performs end of record processing on requests. The 
BAP is released and any buffer segments are unreserved. If 
the processing is being done in map 1, IPCEOR calls NFEOR to 
perform end of record processing. If in map 0, IPCEOR calls 
IPCOBR to complete the end of record processing. 

IPCOBR (in module IPCXFR) 

IPCOBR loads the scheduler map file, calls NFEOBR to perform 
end of record processing, and then reloads the IPC map file. 


IPCCB 

IPCCB creates a BAP, which is described in the section on 
data structure pictures. The BAP describes the data buffer 
of an IPC request. 

IPCXFR 

IPCXFR transfers control between the SVCSHD segment and the 
IPC code segment in map 0, both of which must be mapped as 
the third segment. The IPC map file is loaded and IPCXOP is 
called. After IPCXOP returns, the original map file is 
reloaded and control returns to IPCPRE. 

IPCGQR 

IPCGQR dequeues entries from an IPC channel for processing 
by IPC opcode processors using the following algorithm: 
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WHILE there are processable requests on the CCBABQ or CCBPBQ 
BEGIN 

IF there is an owner request on the CCBABQ 
THEN BEGIN 

dequeue the owner request. 

get the MRBSSI and MRBRCB fields from the call 
block in the MRB. 

IF there is a requester PRB on the CCBABQ 

at the address specified by the MRBSSI and the 
BRORCB field equals the MRBRCB field. 

THEN BEGIN 

dequeue the requester call block from the CCBABQ, 
RETURN to the calling task, returning the matched 
pair of requests. 

END 

ELSE do end -of-record processing on the Master Write, 
returning a NO MATCHING REQUEST error. 

END 

ELSE IF the channel is dead (CCFDED is set) and there is 
a request on the CCBABQ 
THEN dequeue and RETURN the request. 

ELSE IF there is a request on the CCBPBQ 
THEN BEGIN 

IF the request is not from an owner 
THEN IF the request does not require a matching 
owner request OR IF the channel is dead 
THEN dequeue and RETURN the request. 

ELSE RETURN no requests (no match is 

available since owner requests always 
precede requester requests on the 
queue ) 

ELSE BEGIN 

dequeue the request 

IF the owner request does not require a 
matching request 
THEN RETURN the request 

ELSE IF there is a requester request on 
the CCBPBQ 

THEN IF the requester request requires a 
ma t ch 

THEN dequeue the requester request 
and RETURN both requests. 

ELSE BEGIN 

requeue the owner request. 

RETURN the requester request. 

END 

ELSE requeue the owner request 

END 
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IPCOPY 

IPCOPY is used by the IPC request processing routine to copy 
data buffers. IPCOPY uses the nucleus routines NFXCPY and 
NFCOPY to perform the data transfer. IPCOPY expects a 
source address, a destination address, and the number of 
bytes to transfer. The addresses are either specified as 
BAPs (for long distance data transfer) or local addresses. 


10.10 NAME MANAGEMENT 


The Name Manager task handles synonym and logical name segments 
for jobs running under DNOS. It serves SVC requests from user 
tasks and supplies support functions to various pieces of the I/O 
subsystem and to task management. The form of the Name 
Management SVC block Is shown in the section on data structure 
pictures as the NRB. 

Each DNOS task operates with a set of synonyms and/or logical 
names which Is known as a stage. A stage descriptor block (SDB) 
Is maintained In the synonym and logical name segment to describe 
the stage and its relationship with other stages within a job. 
Stages are maintained in a hierarchical order. When a daughter 
stage is created. It Is given a snapshot of Its parent's names. 
This Is Implemented logically rather than making physical copies. 
The stage under which a task Is executing when It issues an SVC 
is known as the current stage of the task. 

The Name Manager serves a queue of requests that include user- 
issued SVCs for SVC opcode >43 and task management entries to 
show when a task Is bid or terminated. Also, lOU queues BRBs for 
the following I/O SVCs: 
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Subopcode 


Descript ion 


90 

91 

92 

94 

95 

96 

97 

98 

99 
9A 
9B 
9D 
9E 
AO 
A1 
A4 


Create File 
Assign LUNO 
Delete File 

Assign Diagnostic Device 
Rename File 
Unprotect FI le 
Write Protect File 
Delete Protect File 
Verify Pathname 
Add Allas 
Delete Allas 
Create IPC Channel 
Delete IPC Channel 
Attach Resource 
Detach Resource 
Modify FDR Bit 


Several of the Name Management SVC subopcodes are described in 
the DNOS SVC Reference Manual , since they are useful in user- 
written code. The subopcodes not described in that manual are 
described in the section on special SVCs in this manual. 


For lOU requests, the Name Manager resolves logical names and 
then places the BRBs on the lOU queue along with any applicable 
Information, such as parameters. These entries may be placed 
back on the Name Manager queue by lOU If a pathname for a job 
temporary file has been autogenerated. 


10.10.1 Architecture of the Name Manager. 

The Name Manager consists of a preprocessor that works in 
conjunction with the SVC request processor to completely buffer 
the request, a queue server task, and a special postprocessor 
that works in conjunction with the main SVC unbuffering routine 
to return information into the user's address space. 


10.10.2 Data Structures Used by the Name Manager. 

Each name segment used by Name Manager uses several data 
structures. Names are organized in stages, with each stage 
representing a complete environment of names. Each stage is 
described by a Stage Definition Block (SDB), including a pointer 
to the stage from which it was built, a task count of the number 
of tasks using the stage, and a pointer to the descendant error 
list. 

Names and their values are organized in balanced binary trees of 
Name Definition Blocks (NDB). An NDB has the name, pointers to 
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the left and right son, a pointer to the lexical successor, a 
pointer to the parent name, and a pointer to the stage value 
block (SVB) list. 

The SVB has flags, a stage number, a pointer to a value 
definition block (VDB) and a pointer to the next SVB. The SVBs 
are kept in descending numerical order of stage number. The VDB 
has a value of a name, a count of the number of SVBs with this 
value, and a pointer to a value continuation block (VCB). The 
VCB has a value and a pointer to another VCB. A VCB is used when 
a name has concatenated files or parameters as values. Figure 
10-14 shows the relationship of these various structures for a 
segment with three names: A, B, and C. Name A is used in three 
stages and has the value .X.Y.FILE. 
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V 

+ + 
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+ + 
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Figure 10-14 Name Segment Structure 


Logical names which are defined to have parameters make use of a 
parameter list structure in the logical name segment. The 
structure is chained to the VCB and is of the following form: 
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Dec Hex 

0 0 

2 2 

4 4 


2+n 2+n 


■k — — — — 

1 Length 1 0 1 

+ + + 

1 Type for Sublist | Length of Subllst | 

+ + + 

I 1 

~ Parameter ~ 

~ Entry Blocks 

I I 

+ + + 


4+n 

6+n 

2+n+m 


4+n I Type for Subllst 1 Length of Subllst 


+ + + 

6+n 1 I 

~ Parameter 

Entry Blocks 

2+n+m I I 

* * 


Requl red 


Opt lonal 


The parameter list contains the following: 

BYTE CONTENTS 

0 Length of entire structure; the sum of 1 
plus two times the number of subllsts. 

1 Zero. 

One or more sets of the following fields: 

2 Type for subllst. The type of the parameters In 
the subllst. Types of parameters are: 

0 - System parameters 

1 - Spooler parameters 
2->7F - Reserved 

>80->FF - User IPC parameters 

3 Length of subllst. The sum of the lengths of all 
parameter entry blocks In the subllst, referred 

t o as n . 

4-3+n Parameter entry blocks, one for each parameter. 

Formats of parameter entry blocks are described . 

In subsequent paragraphs. 

Three formats are defined for parameter entry blocks, one for 
each of the parameter sizes. A parameter may be a single-bit 
binary value, a byte value, or a value of more than one byte. 
Each parameter format Includes a parameter number, and one or two 
bits that identify the format. The parameter entry block format 
for a single-bit value Is: 
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I Parameter No. |1|V| 

The parameter entry block contains the following: 

BIT CONTENTS 

0-5 Parameter number, 0 through 63. Parameter numbers 

need not be assigned or ordered in sequence, but 
must be unique within the sublist. 

6 1 

7 Va lue , 0 or 1 . 

The parameter entry block format for a one-byte parameter Is: 

I Parameter No. |0|0| 

H — — — — — -. — -I -h 

I Value 1 

* * 

The parameter entry block contains the following: 

BYTE CONTENTS 

0 Parameter number byte: 

Bits 0-5 - Parameter number, 0 through 63. 

Parameter numbers need not be assigned 
or ordered in sequence, but must be 
unique within the sublist. 

Bit 6-0 
Bit 7 - 0 

1 A numeric value, 0 through 255, or an ASCII 

character . 
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The parameter entry block format for a multi-byte parameter Is: 

I Parameter No« iO|l| 

1 Parameter Length | 

+ + 

1 I 

~ Parameter 

~ Value 

I I 

* * 

The parameter entry block contains the following: 

BYTE CONTENTS 

0 Parameter number byte: 

Bits 0-5 - Parameter number, 0 through 63. 

Parameter numbers need not be assigned 
or ordered In sequence, but must be 
unique within the subllst. 

Bit 6-0 
Bit 7 - 1 

1 Parameter length. The number of bytes required 
for the parameter value. 

2-nn Parameter value. The numbers or characters of 

the parameter. 

The parameter list consists of one or two subllsts. All 
parameters In a subllst are of the same type. Each parameter Is 
Identified by a parameter number In the range of 0 through 63. 
The parameters In a subllst must have unique parameter numbers. 
They may be numbered In any sequence, skipping numbers, or not, 
as req ul red . 


10.10.3 Name Manager SVC Preprocessing. 

When a Name Manager SVC Is Issued, control Is passed to the SVC 
decoding routine. This routine buffers the user call block Into 
STA along with the BRO. The decoding routine then passes control 
to the Name Manager preprocessor, with the BRB on the Name 
Manager queue. This BRB has the form: 
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Buffered Request Overhead 
User's call block as follows: 

SVC code 43, error code 
subopcode , flags 

other fields depending on the entry type 
Space for extra words of Name Manager Information 


The Name Manager preprocessor works with the SVC buffering 
routine to buffer call block extensions as needed, depending on 
the SVC number and subopcode. It also retrieves (from the user's 
JCA) the ID of the requesting task, the stage number, and the 
name segment SSB address. It stores these values In the extra 
words of space for Name Manager Information. Before an lOU 
request reaches the Name Manager, the lOU preprocessor also 
gathers the stage number and the name segment SSB address and 
stores them In a three -word block following the standard buffered 
I/O request block. 


10.10.4 Details of Name Manager Modules. 


The Name Manager consists of several processors and a short 
section of code that selects one of these processors depending on 
the SVC code and the subopcode. The entries are: 


NMMAPN 

NMGNPN 

NMSETN 

NMAPNV 

NMDELN 

NMFLEX 

NMPURG 

NMENS 

NMRTPS 

NMGDEL 

NMGSSZ 

NMSAVE 

NMCTC 

NMIOU 

NMREST 


Determine Name's Value 

Determine Next Pathname of Name's Value 
Create Logical Name/Assign Synonym 
Append Pathname to Present Value of Name 
Delete Name 

Find Lexical Successor 

Purge Names 

Enter New Stage 

Return to Previous Stage 

Get Next Descendent Error List Entry 

Get Segment Size 

Save Names to a File 

Notice of Task Bid or Termination 

Pass SVC to lOU after Resolving 

Logical Names 

Restore Names from a File 


A description of each of the entry processors follows. 


NMMAPN - Determine Name's Value 

For either synonyms or logical names, this operation returns 
the value of the name to the requester. If the Name Manager 
finds the name specified. It returns the value string to the 
buffer specified by bytes 6 and 7 In the call block. For 
logical names, any parameters defined for the name are also 
returned, using the buffer to which bytes 8 and 9 of the 
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call block point. Byte IQ Is set to 0. If the logical name 
Is assigned to a set of files that have been logically 
concatenated, only the first file pathname Is returned and 
byte 11 Is set to the value 1. Otherwise, byte 11 Is set to 

0 . 

NMGNPN - Determine Next Pathname of Name's Value 

This Is used to determine the various pathnames In a set of 
logically concatenated files. Only one pathname Is returned 
by this operation. This pathname corresponds to the 
pathname number specified In bytes 10 and 11. (The number 0 
returns the first pathname, 1 returns the second, and so 
on.) In addition to returning a pathname, the processor 
also Increments this word (bytes 10 and 11) If the pathname 
returned Is not the last one In the list of concatenated 
files. If the pathname Is the last one, the processor 
returns 0 to bytes 10 and 11. 

NMSETN - Create Logical Name/Assign Synonym 

This serves either of two functions, depending on the flag 
set by the user to tell whether this Is a synonym or a 
logical name operation. If It Is a synonym operation, the 
Assign Synonym operation Is performed, using the name as a 
synonym name and giving that name the specified value. Any 
previous value for the synonym Is replaced with the new 
value. Stage scope rules (described In paragraphs that 
follow) are strictly followed In the process of assigning 
the new value to the name. 

If a logical name operation Is Indicated, a Create Logical 
Name operation Is performed. The specified name Is given 
Its value (pathname), and any parameters specified are 
associated with the logical name. As with synonyms, any 
previous value for the logical name Is replaced, and stage 
scope rules are strictly followed. If the logical name Is 
for a pathname that Is to have Its last component filled In 
by lOU (unique pathname to be aut og ene r a t ed ) , space for the 
pathname to be supplied Is reserved at the end of the value 
field within the table entry. However, the length of the 
value Is recorded as the length specified by the user and 
does not change until lOU notifies the Name Manager of the 
full pathname. 

NMAPNV - Append Pathname to Present Value of Name 

This operation adds to a logical name that represents a set 
of logically concatenated files. The pathname for the first 
file and all parameters to be associated with the logical 
name are specified with the Create Logical Name operation. 
Additional pathnames may then be appended, one at a time, by 
using this operation. The additional pathnames are stored 
separately In the logical name segment to avoid having to 
move the previous name definition to a location large enough 
to accommodate the additional pathnames. The additional 
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pathnames are linked to the name definition in the order 
they are supplied by the user. 

NMDELN - Delete Name 

Depending on the flag setting, the name is deleted from the 
synonym table or the logical name table. Any appended 
pathnames are also deleted. If the name represents a job- 
local temporary file, a Detach Resource operation is 
performed on the resolved name. Stage scope rules are 
strictly followed so that deleting the name does not affect 
the definition seen by other stages within the same job. 

NMFLEX - Find Lexical Successor 

This routine searches the synonym or logical name 
definitions, as specified, for the name (if one exists) that 
is the Immediate alphabetic predecessor or successor of the 
specified name (pointed to by bytes 4 and 5). Whether the 
predecessor or successor is found depends on the value of 
the word at bytes 10 and 11 (0 indicates successor, -1 
indicates predecessor). If the desired name is found, its 
name replaces the specified name (pointed to by bytes 4 and 
5) and its value is placed in the buffer pointed to by bytes 
6 and 7. If parameters are associated with the name and the 
parameters buffer pointer (bytes 8 and 9) is nonzero and 
points to a nonzero-length buffer, the parameters are 
returned in the buffer. If no name is found to meet the 
requirements, a null string (zero length) replaces the 
specified name. If the specified name points to a zero- 
length string, the alphabetically smallest name and its 
value is returned if the successor was requested; the 
alphabetically largest name and its value are returned if 
the predecessor was requested. If the value pointer 
originally is zero or points to a zero-length string, any 
name found is returned as usual, but its corresponding value 
1 s oml 1 1 ed . 

The name buffer to which the call block points must be large 
enough to hold the maximum results possible, even though the 
first byte shows only the length of the string that 
currently occupies the buffer. This routine cannot check to 
ensure that the buffer is large enough. 

NMPURG - Purge Names 

This SVC provides the capability to delete a series of names 
that are (in some sense) logically related. It searches all 
names for those that have the first n-1 bytes exactly the 
same as the first n-1 bytes of the specified name. Each 
time such a name is found, the nth bytes are compared. If 
the nth byte of the name is greater than or equal to the nth 
byte of the specified name, the name found is deleted. 
Otherwise, the name is left Intact. The length of the name 
deleted may be greater than or equal to the specified name. 
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NMENS - Enter New Stage 

A new stage Is created with a stage number equal to the 
lowest number not currently used In the job, and the 
requesting task Is placed Into the new stage. This Involves 
allocating an SDB for the new stage, and placing a new stage 
number In the TSB of the requestor. 

NMRTPS - Return to Previous Stage 

This operation returns the task to the stage In which It was 
running previous to Its last Enter New Stage operation. 
This operation Is valid only when the task Is returning to a 
stage from which It Issued an Enter New Stage SVC. If the 
task count of the current stage Is greater than one, the 
task count Is decremented and the stage number field Is 
adjusted In the TSB of the requesting task. If the task 
count Is only one, the current stage must be deleted. This 
requires the following: 


* Appending any entries In the current stage's descendant 
error list onto the descendant error list of the parent 
stage for the current stage 

* Searching the current stage's synonyms for $$CC and. If 
It Is found, building another entry on the parent 
stage's descendant error list 

* Deleting all synonyms and logical names that are defined 
at the level of the current stage 

* Delinking and deallocating the current stage's SDB 

The descendent error list Is a set of synonyms used for SCI 
to pass error Information from one stage to its parent and 
to allow a background task to report error Information to 
the foreground SCI. It consists of values for the synonyms 
$$CC, $$ES, $$FN, $$MN, and $$VT. 

Whether or not the stage Is to be deleted, the requesting 
task may also specify a list of synonym names to be passed 
to the parent stage. The names must be placed back-to-back 
In a buffer to which bytes 4 and 5 point, with the length of 
each name (In bytes) Immediately preceding the name. The 
length of the entire list must be specified in the first 
byte of the buffer. 

NMGDEL - Get Next Descendent Error List Entry 

This returns the first entry on the descendent error list 
and then deletes that entry. The entry Is returned in the 
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value buffer to which bytes 6 and 7 point and consists of 
the values that the synonyms $$CC, $$ES, $$MN, $$FN, and 

$$VT had when the entry was made. Entries are made when a 
daughter stage that has values defined for these five 
synonyms terminates. The values are returned back-to-back 
in the buffer. The first byte of the buffer must be set up 
by the requester to indicate the length of the buffer. Upon 
completion of the SVC, the first byte contains the length of 
the entry returned (0 if none). 

NMGSSZ - Get Segment Size 

This returns no error if the job contains synonyms ; 
otherwise, an error is returned. 

NMSAVE - Save Names to a File 

This physically copies all currently accessible names to the 
file whose pathname is specified in bytes 4 and 5. The file 
is built with only the names that are linked to the SDB for 
that stage. The file can be on any disk. The pathname is 
of the same format used to assign LUNOs . 

NMCTC - Notice of Task Creation or Termination 

Since the Name Manager must maintain a task count for each 
stage, task management places an entry on the Name Manager 
queue whenever a task is bid and whenever a task terminates. 
Task management does not suspend while this entry is 
processed. A task inherits its stage number from the 
creator task. The initial task of a job gets a stage number 
of zero. The call block format for this call is shown as 
the name request block (NRB) in the section on data 
structure pictures. It uses a pseudo-subopcode >0C. 

NMIOU - Pass SVC to lOU after Resolving Logical Names 

All lOU operations that have an access name as one of their 
arguments are queued to the Name Manager to be processed and 
passed to lOU. The Name Manager resolves any logical names 
to their full pathnames and then passes the BRB to lOU. The 
Name Manager allocates STA for the full pathname and for any 
associated parameters and modifies the BRB to point to those 
structures. When lOU autogenera tes a pathname for a logical 
name, it places the BRB back on the Name Manager queue so 
that the Name Manager can update the logical name with the 
full pathname . 

NMREST - Restore Names from a File 

Names are restored to a name segment from the file pointed 
to by bytes 4 and 5 of the call block. The name segment ID 
is returned in bytes 12 and 13 of the call block. Only one 
stage exists in this segment, stage 0. 
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10.10.5 Stage Scope Rules. 

Stage scope rules are used to ensure that each stage has Its own 
set of synonyms and logical names. These rules also enable one 
stage to make changes to these names without affecting the values 
of these same names for other stages. These rules are 
circumvented only when executing a Return to Previous Stage 
operation with names specified or when executing an lOU request 
that involves autocreation of a file whose logical name was 
previously assigned. 

Rule 1 

When a previously undefined name Is defined, the value 
definition block Is queued to the NDB of the requesting 
stage only and is not accessible by other stages. 

Rul e 2 

When a name's value (as seen by the requesting stage) Is 
changed, the previous (If any) value definition block In the 
chain of the requesting stage is discarded and a value 
definition block for the name is built and queued to the SDB 
of the requesting stage only and is not accessible by other 
stages. 
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SECTION 11 

DISK STRUCTURES AND FILE I/O 


11.1 OVERVIEW OF FILE MANAGEMENT 

File management handles I/O operations directed to disk files. 
Code in the subsystem runs at either task level or XOP level, 
depending on the stage of processing and the particular operation 
involved. As with other I/O operations, handling begins in the 
request processing modules of the operating system, with some 
preliminary work handled by the general I/O preprocessor lOPREP; 
then, action is taken by the file management code Itself, The 
Initial work of file management occurs at the XOP level, with the 
JCA of the calling job mapped into the second segment of map file 

0. Processing proceeds until an SVC (or direct I/O) must be 
Issued. At this point, a change is made to the file management 
task-level code. 


11.2 STRUCTURE OF A NEW DISK 

Before a disk can be initialized for use by file management, it 
must be checked for surface defects. This is done by the 
Initialize Disk Surface (IDS) utility. Any defective tracks 
found by vendor testing must be entered when the IDS command is 
executed. The IDS utility does not always find all defective 
tracks on a disk. 

When using the IDS utility, the user has the option of 

initializing the disk for DNOS use or leaving the disk 
uninitialized. When left uninitialized for DNOS, the format of 
the disk after running the IDS utility is as follows: 

1. Track 0, sector 0 has all zeros except in the word that 

shows the state of the disk (SCOSTA). This word has 

the value 2 , 

2. Track 0, sector 1 contains a list of bad (defective) 

tracks. The list consists of pairs of words terminated 

by a word of zero. The first word of each pair 

contains the head and cylinder number of the first 
track of a contiguous set of bad tracks. The head 

number is in bits 0 through 4 of the word, and the 
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cylinder number is in bits 5 through 15. The second 
word of each pair is the number of bad tracks in this 
contiguous set. 


The disk surface is required to be initialized with IDS only 
once. The disk may then be initialized for use by DNOS with the 
Initialize New Volume (INV) command as often as needed. The 
information about defective tracks is preserved when an INV is 
done, but the information can be extended by specifying 
additional defective tracks. 

The INV utility functions only if the disk has a value of 2 or 3 
in SCOSTA of track 0, sector 0. The value of 2 is placed there 
by the IDS utility, and the value of 3 is placed there by INV. 
For all other values of SCOSTA, the disk is considered not to 
have the surface initialized. 


11.3 DISK DATA STRUCTURES 

File management uses a number of data structures on disk volumes 
as well as a number of In-memory data structures to process disk 
I/O requests. The structures on disk Include information 
describing the disk and structures describing each file on the 
volume. Each of these structures is described in the section on 
data structure pictures. 

Under DNOS, all tracks on disks are Initialized in physical 
records of one sector per record. Note that this record is a 
disk characteristic and is not the same as the physical record 
size specified when files are created. 

DNOS disks are logically divided into allocatable disk units 
(ADUs), an Integral number of sectors on the disk; the number of 
sectors per ADU varies according to disk size (see Table 11-1). 
The number of ADUs is always less than 65,536 (that is, each ADU 
on the disk can be addressed in a 16-blt word). The number of 
sectors per ADU is always 1 or a multiple of 3. ADUs are 
numbered from 0, with the first starting on track 0, sector 0. 
Table 11-2 shows the capabilities of available disks. 
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Table 11-1 Format Information for Available Disks 



Ava 1 1 

No. 

No . 






Space 

of 

of 

No . of 

Sectors 

Sectors 

Bytes 

Disk Type 

(MB) 

ADUs 

Heads 

Cyl Inde r s 

/Track 

/ADU 

/Sector 

DSIO 

4.7 

16320 

2 

408 

20 

1 

288 

DS25 

22.3 

25840 

5 

408 

38 

3 

288 

DS31/DS32 

2.81 

9744 

2 • 

203 

24 

1 

288 

DS50 

44.6 

51616 

5 

815 

38 

3 

288 

DS200 

169.5 

65381 

19 

815 

38 

9 

288 

FDl 000 

1 .15 

4004 

2 

77 

26 

1 

288 

CMD 16 

13.5 

53196 

1 

806 

66 

1 

256 

CMD 80 

67.3 

44330 

5 

806 

66 

6 

256 

DS80 

62.7 

40819 

5 

803 

61 

6 

256 

DS300 

238.3 

62045 

19 

803 

61 

15 

256 

WD800-18 

18.5 

2231 1 

3 

603 

37 

3 

256 

WD800-43 

43.2 

52059 

7 

603 

37 

3 

256 

WD800A-43 

42.8 

55744 

3 

871 

64 

3 

256 

WD800A-100 

99.9 

65034 

7 

871 

64 

6 

256 

WD500 

4.75 

18560 

4 

145 

32 

1 

256 

WD500A 

17.0 

22208 

3 

694 

32 

3 

256 



Table 11- 

2 Capabilities of 

Ava liable 

Disks 



Read 

Read 

Variable 



Bad 

Disk 

With 

With 

Inter- 

Diagnos t i c 

Transfer 

Track 

Type 

Strobing 

Offsets 

leave 

Cyl inde rs 

Inhibit 

Mapping 

DSIO 

NO 

NO 

NO 

NO 

YES 

NO 

DS25 

YES 

YES 

NO 

NO 

YES 

NO 

DS31/DS32 

NO 

NO 

NO 

NO 

NO 

NO 

DS50 

YES 

YES 

NO 

NO 

YES 

NO 

DS200 

YES 

YES 

NO 

NO 

YES 

NO 

FDIOOO 

NO 

NO 

YES 

NO 

YES 

NO 

CMD 16 

YES 

YES 

NO 

YES 

YES 

NO 

CMD 80 

YES 

YES 

NO 

YES 

YES 

NO 

DS80 

YES 

YES 

NO 

YES 

YES 

YES 

DS300 

YES 

YES 

NO 

YES 

YES 

YES 

WD800-18 

YES 

NO 

NO 

YES 

YES 

NO . 

WD800-43 

YES 

NO 

NO 

YES 

YES 

NO 

WD500 

NO 

NO 

YES 

YES 

YES 

NO 

WD500A 

NO 

NO 

NO 

YES 

YES 

NO 

WD800A-43 

YES 

NO 

NO 

YES 

YES 

YES 

WD800A-100 

YES 

NO 

NO 

YES 

YES 

YES 
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All disks that have been initialized under DNOS have the 
following physical layout: 

* Track 0, sector 0 — Contains information about the disk 
volume, such as the volume name and pointers to the 
volume directory (VCATALOG). Template SCO describes the 
Information here. 

* Track 0, sector 1 — Contains a list of bad (physically 
imperfect) areas on the disk. Each entry Is two words: 
the first word is the address of the first bad ADD; the 
second word is the address of the last bad ADU. A zero 
word terminates the list. 

* The remainder of track 0 contains disk allocation 
information in the form of bit maps. 

* Track 1, sectors 0 to N-2 — Optionally reserved for the 
disk program image loader. 

* Track 1, next to last sector — A copy of track 0, 
sector 0 . 

* Track 1, last sector — A copy of track 0, sector 1, 

* Highest numbered (Innermost) cylinder -- Diagnostic 
information. This appears on disk maps as the file 
.S$DIAG. 

* The remaining tracks are available for file allocation. 


11.3.1 Volume Information, 

The information contained in track 0, sector 0 of all disks 
initialized under DNOS is called volume information. This block 
is detailed in the section on data structure pictures as SCO, 
Sector 0, Track 0. 


11,3.2 Allocation Bit Map. 

To keep track of which areas on the disk are allocated and which 
are free, the DNOS disk manager maintains a bit map of allocated 
ADUs. The bit map is located on track 0 of each disk, starting 
at sector 2 and continuing through as many sectors as necessary. 

The bit map is divided into 128-word partial bit maps (PBMs), 
Each PBM is located in a separate sector on track 0, The first 
word of each PBM contains the number of the ADU that begins the 
largest block of free disk space located in the part of the disk 
that is mapped by the PBM. Each bit in the remaining 127 words 
represents an ADU. If a bit is 0, the ADU is free; if a bit is 
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1, the ADU is allocated or bad. Each PBM contains 127 16-blt 
words of information and maps 2,032 ADUs. 


11.4 FILE STRUCTURES 

DNOS supports three file types: relative record files (blocked 
and unblocked), sequential files, and key Indexed files. All 
file types are based on the unblocked relative record type, with 
extra system overhead needed to Implement sequential and key 
indexed files. Also, three special types of relative record 
files are available: program files, directory files, and image 
files. 

In the following discussion of file types and structures, a 
physical record of a file is the amount of data actually 
transferred by the operating system during an I/O operation to 
the file; a logical record of a file is the amount of information 
the user transfers in one (not multiple) Read or Write SVC call. 
The ratio of the logical record size to the physical record size 
is called the blocking factor. 


11.4.1 Relative Record Files. 

A relative record file is a file in which all logical records are 
of a fixed length and each record can be randomly accessed by its 
unique record number. Relative record files may be unblocked 
(physical record size accommodates only one logical record) or 
blocked (physical record size accommodates more than one logical 
record ) . 


11.4.1.1 Unblocked Relative Record Files. 

Each logical record of an unblocked relative record file occupies 
one physical record of the file. A physical record may be any 
Integral multiple of contiguous sectors. File accesses require 
reading or writing this number of sectors (reads and writes of 
multiple contiguous sectors can be accomplished via one disk 
access). Records read from unblocked relative record files are 
transferred directly from the disk to the user buffer, without 
Intermediate system buffering. When the user specifies a 
particular record of the file, the record number is converted by 
file management to an absolute ADU number and a sector offset 
within the ADU. The absolute disk address is then passed to the 
disk DSR to perform the actual data transfer. The disk DSR 
converts the ADU and relative sector to a physical track and 
sector disk address to communicate with the disk controller 
hard wa re. 
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The diagrams that follow show examples of long unblocked relative 
record files and short unblocked relative record files. Assume 
that the disk in use has 9 sectors per ADU. In the first 
example, the record might span 3 ADUs, perhaps occupying a total 
of 25 sectors. Thus, 2 sectors are wasted per physical record. 
In the second example, each physical record might occupy 2 
sectors, wasting 1 sector of each ADU. 


Long Unblocked Relative Record File 
Record Size > ADU Size 


LONG UNBLOCKED RELATIVE RECORD , RECORD SIZE > ADU SIZE 

RECORD 



2278129 ADU 


Unblocked Relative Record File 
Record Size < ADU Size 


PHYSICAL 


LOGICAL 





2278486 



ADU 


Note that each physical record must begin on a sector boundary. 
Also, a physical record that starts in the middle of an ADU may 
not span the ADU boundary. 

11.4.1.2 Blocked Relative Record Files. 

Files of blocked relative records are treated the same as 
unblocked files except that multiple logical records may be 
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stored in each physical record. Logical records may not span 
physical records. Records are transferred via intermediate 
blocking buffers, which are furnished from the general pool of 
user space by buffer management. 

Note that each physical record must begin on a sector boundary 
and that a physical record that starts within an ADU cannot span 
the ADU boundary. Also, when physical records are less than an 
ADU, the number of sectors actually taken up by a physical record 
is the number of sectors per ADU divided by the number of 
physical records per ADU. 

In the figure which follows, assume that the disk in use has 9 
sectors per ADU. If a physical record occupies 3 sectors, three 
of these physical records would fit into each ADU. Each physical 
record begins on a sector boundary, so there is no unused space 
at the end of each ADU, but there may be unused space at the end 
of each physical record if the logical record size is not an 
exact multiple of the physical record size. The figure shows 
each physical record composed of 4 logical records and some 
unused space . 


Blocked Relative Record File 


PHYSICAL RECORD 1 


RECl 

REC2 

REC3 

REC4 





4 LOGICAL RECORDS 

UNUSED 


2278485 


PHYSICAL RECORD 2 


REC5 

REC6 

REC7 

REC8^^ 




Yyyj 


4 LOGICAL RECORDS 

UNUSED 

yy 

ADU 


PHYSICAL RECORD 3 


REC9 

REC 

1 0 

REC 

1 1 

REC 

1 2 

m 


4 LOGICAL RECORDS 

UNUSED 


11.4.2 Sequential Files. 

Sequential files are blocked relative record files with variable- 
length logical records. Logical records may span physical record 
boundaries regardless of ADU boundaries. When a logical record 
spans a physical record boundary, it is broken into partial 
records contained in separate blocks. The first word of each 
physical record has two flags indicating whether the first 
logical record is continued from the preceding physical record 
and whether the last logical record is continued in the following 
physicalrecord. 
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When set to 1, flag bits have the following meanings: 

* Bit 0 - First logical record in this physical record Is 
continued from the preceding record 

* Bit 1 - Last logical record in this physical record 
continues in the next record 

Each logical record or partial record is preceded by a header 
word and followed by a trailer word. The content of the header 
and trailer is the number of bytes of data between them. An end- 
of-file is signified by a zero value header and trailer. A zero 
length record is indicated by a header and trailer containing 
>FFFF . 

A special condition exists when a record or last partial record 
ends with only one or two words remaining in the physical block. 
Since there is not room for another partial record 
( heade r /da t a / t ra i le r ) , the next record begins in the following 
block. The last word of the current block contains the number in 
the last trailer plus the number of unused bytes (two or four). 
Figure 11-1 shows how a sequential file is arranged. 

Logical records of a sequential file may be blank-suppressed 
(defined as blank-suppressed when created). In blank-suppressed 
files, all full words of blanks are removed. A blank-suppressed 
logical record includes a header word, a set of data, and a 
trailer word. The set of data Includes one or more repetitions 
of a byte containing a count of words of blanks, a byte 
containing a count of words of characters with no words of 
blanks, and data characters. If a logical record has a length of 
zero, the physical record shows two words of FFFF. Figure 11-2 
shows a blank-suppressed record. 
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Input Record : 

column : 0 0 1 1 2 

1 5 0 5 0 

FIRST LAST 

Physical Record on File: 
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Figure 

1 1-2 

Blank- 

Suppressed Record 




11.4.3 Key Indexed Files. 

Key Indexed files have variable-length logical records that can 
be accessed either randomly, by any of up to 14 keys, or 
sequentially. In the sort order using any key. On the disk, a 
key Indexed file with n keys Is arranged as follows: 

* The first 18n+3 (n=number of keys) physical records are 
the KIF prelog blocks. Before a record In the file Is 

modified. It is written Into a prelog block to prevent 
data loss In case of an error (for example, power 
failure) during the data transfer or in case the 
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operation is partially completed when an error occurs. 

If an error occurs, the logged blocks are written back 
into the original file* record when the file is next 
opened (in the case of a S'ystem crash) or before the 
operation terminates (in. tbe case of user errors), and 
the file operation may be retried. 

* The next n physical records are the roots of the 
balanced trees (B-trees) that are used to locate each 
logical record within the file by key. Every defined 
key has a corresponding B-tree (up to 14 B-trees); 
therefore, each key indexed file has n B-tree roots. 

* Following the B-tree root nodes are physical records 
that contain data as well as those that contain other B- 
tree nodes. 

B-trees are made up of a root node, branch nodes, and leaf nodes. 
A root node is the first node of the tree. Leaf nodes contain 
pointers to the data records. Branch nodes are all of the nodes 
between the root and leaf nodes. A root node may be a leaf node, 
in which case there are no branch nodes. 

A DNOS B-tree has multiple branches per node and all leaf nodes 
are at the same level. DNOS B-trees may not exceed nine levels. 
Figure 11-3 shows a sample B-tree in which the key values are 
single letters. 

Each node of a B-tree occupies one physical record of a key 
indexed file, and is called a B-tree block (BTB). Each BTB 
contains 18 bytes of overhead and several polnter/key value 
entries. These entries are sorted in increasing order of key 
value (smallest key value is the first entry). 

If the block is not a leaf entry, each pointer field points to a 
subtree that contains key values less than or equal to the key 
value associated with the pointer. In fact, the highest key 
value contained in the subtree is the key value associated with 
the pointer (as shown in the sample B-tree). 

Further information on general B-tree structure is available in 
The Art of Computer Programming, Volume III by Donald Knuth. 
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All of the data records ( logical records ) of a key indexed file 
are contained in data blocks. . A. data block is a physical record 
of the file and contains 14 bytes of overhead and several logical 
records. The word following the -last logical record has a zero 
value. The structure of a KIF information block (KIB) is shown 
in the section on data structure pictures. 

Whenever a data record is to be'lnserted in a data block, it is 
assigned an ID that is unique within the block. The data record 
is then Inserted after the last logical record in the block. 


11.4.4 Program Files. 

In addition to the three basic file types, three special uses of 
the relative record file warrant description: program files, 
directory files, and image files. 

Program files are unblocked relative record files with a logical 
record size of one sector. The sector size is hardware 
dependent, with the smallest sector size being 256 bytes. Figure 
11-4 shows the format of a program file. The program file 
directory index entry (PFI) and the program file record zero 
(PFZ) are shown in detail in the section on data structure 
pi c tures . 

The sections of information describing the contents of the 
program file do not always start at the beginning of records or 
in the same place for all program files. The following equations 
define the record number and the offset into the record which 
defines the beginning of the information. In the equations, R 
designates a record and F designates the offset. 

R1 = 1 
FI = 0 

R2, = R1 + {((MAX # TASKS +2)/2) * >10) + FI} / >100 

F2 = remainder of {((MAX # TASKS +2)/2) * >10 + FI} / >100 

R3 = R2 + {(MAX # TASKS +1) * >10 + F2} / >100 

F3 = remainder of {(MAX # TASKS +1) * >10 + F2} / >100 

R4 = R3 +{((MAX # PROGS +2)/2) * >10 + F3} / >100 

F4 = remainder of {((MAX # PROGS +2)/2) * >10 + F3} / >100 

R5 = R4 +{(MAX // PROGS +1) * >10 + F4} / >100 

F5 = remainder of {(MAX # PROGS +1) * >10 + F4} / >100 

R6 = R5 +{((MAX # OVLYS +2)/2) * >10 + F5} / >100 


2270512-9701 


11-13 


File I/O 



DNOS System Design Document 


F6 = remainder of {((MAX # OVLYS +2)/2) * >10 + F5} / >100 

F7 = R6 +{(MAX # OVLYS +1) * >10 + F6} / >100 

F7 = remainder of {(MAX # OVLYS +1) * >10 + F6} / >100 

R8 = R7 + {((MAX // HOLES * 4) +2) + F7} />100 

F8 = remainder of {((MAX // HOLES * 4) +2) + F7} / >100 


If F8 is not equal to zero, then R8 = R8 + 1 


R1 ,F1 
R2 ,F2 
R3 ,F3 
R4 ,F4 
R5,F5 
R6,F6 
R7,F7 
R8 : 


Record number and offset for 
Record number and offset for 
Record number and offset for 
Record number and offset for 
Record number and offset for 
Record number and offset for 
Record number and offset for 
Record number of first image 


names of tasks, 
task directory entries, 
names of procedures, 
procedures directory entries, 
names of overlays, 
overlay directory entries, 
unused space directory, 
record . 


The first record (record number 0) of a program file contains six 
bit maps. These bit maps. In order of occurrence within record 
0, are for memory-resident tasks, memory-resident procedures or 
segments, all tasks, all procedures, all nonrepli cat able tasks, 
and all overlays. 


* * 

0 I OVERHEAD RECORD | 

H — — — — — — — — — — — — — _ — — — — — — 

1 I NAME ENTRIES FOR TASKS | 

R2:02 I DESCRIPTION ENTRIES FOR TASKS | 

+ + 

R3;03 I NAME ENTRIES FOR PROCEDURES /SEGMENTS | 

+ + 

R4:04 1 DESCRIPTION ENTRIES FOR PROCEDURES/ SEGMENTS | 

R5;05 I NAME ENTRIES FOR OVERLAYS | 

+ + 

R6:06 I DESCRIPTION ENTRIES FOR OVERLAYS | 

R7:07 I AVAILABLE SPACE LIST | 

+ + 

R8 I IMAGE FORMATS FOR TASKS, PROCEDURES AND OVERLAYS | 

* * 


Figure 11-4 Program File Format 


When record 0 Is Initialized, all bits In the bit map are 0 
except the first bit In the tasks, p r oced ur e s / s e gmen t s , overlays. 
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and nonrepli eatable tasks bit maps (the bit maps occupying bytes 
>54 through >D3). The first bit of these is a 1, restricting 
user tasks from allocating ID 0. 

Each bit map has 16 words, with 16 bits per word; therefore, each 
bit map can represent 256 IDs. A bit set to 1 indicates that the 
ID corresponding to the bit position (0 through 255) is assigned 
to a task, procedure, or overlay segment installed in the file. 
The format of record 0 of the program file is shown in the 
section on data structure pictures as PFZ, Program File - Record 
Zero. 

When a program file is created, the maximum number of tasks, 
procedur es / segment s , and overlays to be set into bytes >D4, >D8, 
and >DC of record 0 are defined by the creator of the program 
file. The maximum number of holes, which equals the sum of these 
three values, is used to calculate the number of bytes required 

in the overhead records for the available space list. This list 

is headed by a word containing the number of entries in the list. 
The rest of the list consists of two-word entries that describe 
the unallocated spaces (holes) in the image portion of the 

program file. Each entry contains the starting record number and 
the number of available records in each hole. A hole appears 
when an image is deleted. The hole is recorded to be used again 
if a new image that is the same size or smaller than the deleted 
one is installed in the file. Adjacent Images, when deleted, 
create only one hole. Figure 11-5 shows the format of the 

available space list. 
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* 

I 

+ 

I 

+ 

I 

+ 


+ 

I 

+ 

I 

•k 


NUMBER OF ENTRIES 


RECORD NUMBER 


RECORDS AVAILABLE 


RECORD NUMBER 


RECORDS AVAILABLE 


-* 

I 

-+ — + 

I 1 

-f entry 1 
I I 
-+ — + 

I 

/ 

I 

-+ — + 

I I 

-+ entry n 
I I 


Figure 11-5 Program File Available Space List 


The available space list uses the entire record, not 256 bytes of 
it as the other overhead records do. Therefore, if the list 
spans records, an entry is split across two records. (The first 
word of the entry is the last word of one record, and the second 
word of the entry is the first word of the next record.) The 
available space list is Initialized at the same time record 0 is 
initialized. Its values are as follows: 


* * 


I 

1 

1 ONE HOLE 

1 

R8 

1 BEGINS AT RECORD 8 

1 

>FFFF-R8 

1 IS >FFFF - R8 RECORDS LONG 


k * 


R8 is the record number of the first record following 
the available space list. 

The maximum number of records permitted in a program is >FFFF . 
Thus, the maximum number of image records permitted in a program 
file is >FFFF minus the number of overhead records. 

The actual image of a task, procedure, or overlay must start on a 
record boundary in the program file. If the segment has a 
relocation bit map, the map begins at the first word following 
the program segment image. However, any part of a program file 
can be split across secondary allocations. The relocation bit 
map begins at the first word following the program segment image. 
The length of the relocation bit map is the length of the program 
segment image, in bytes, divided by eight and rounded to a word 
boundary 
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The task, procedure / segment , and overlay name entries in the 
program file contain the names of -all tasks, pr oced ur es / s egme nt s , 
and overlays Installed In the program file. A name entry Is 
eight bytes long, blank-filled to the right. The name entry Is 
placed in the name block position that corresponds to the ID 
assigned to that segment. For example, if task GENTX is assigned 
ID 1 , the name GENTX is entered in bytes 8 through 15 (second 
position) of the name entries block for tasks. 

The task, procedure/ segment , and overlay description entries in 
the program file contain information about all segments installed 
in the program file as well as pointers to the segment Images. 
Each description is 16 bytes long. The figures that follow show 
the formats of the program file description entries, with field 
descriptions following each format. Figure 11-6 shows the format 
of the task description; Figure 11-7 shows the format of a 
procedure/ segment description; and Figure 11-8 shows the format 
of an overlay description. 


Hex . 

Byte 

A — — it 

>00 I LENGTH OF TASK SEGMENT 1 

+ 

>02 I FLAGS I 

+ -H 

>04 I RECORD NUMBER 1 

+ + 

>06 I DATE INSTALLED | 

+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + 

>08 I LOAD ADDRESS | 

+ + + 

>0A I OVERLAY LINK | PRIORITY OF THE TASK | 

+ 4- -H 

>0C 1 PROCEDURE 1 ID | PROCEDURE 2 ID | 

+ + + 

>0E 1 TASK LENGTH | 

* * 


>10 maximum size 

Figure 11-6 Task Description Entry 
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Hex . 

Byte Description of Selected Fields 


>00 

>02 


>04 

>06 


>08 

>0A 


>0E 


Length of task segment in bytes. Length of task root 
plus length of the task's longest overlay path. 

Flags, as follows: 

Bit Meaning When Set 


0 Privileged 

1 System 

2 Memory resident 

3 Delete protected 

4 Repllcatable 

5 Procedure 1 is on the system program file 

6 Procedure 2 is on the system program file 

7 Directory entry in use 

8 Overflow 

9 Writable control store (WCS) 

10 Execute protected 

11 Software privileged 

12 Updatable 

13 Reusable 

14 Copyable 

15 Security bypass 

Record number. Logical record number of the start 
of the task image in the program file. 

Date installed, in the following format: 

Bit Meaning 

0-6 Year (displacement) 

7-15 Julian date 

Load address. Relative starting address within a 
mapped task segment. Must be on a beet boundary. 

Overlay link. The ID of the most recently Installed 
overlay associated with the task. Each overlay entry is 
in turn linked to the next entry so that tasks can be 
associated with their overlays when status or delete 
commands are executed. A value of 0 is used to 
terminate the list. 

Task length. Last defined task code. If a BSS is the 
last instruction in the task, its length is not included 
1 n the value . 
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Hex . 

Byte 

* ' * 

>00 1 LENGTH OF PROCEDURE/ SEGMENT (BYTES) | 

+ + 

>02 I FLAGS 1 

>04 1 RECORD NUMBER I 

+ • + 

>06 1 DATE INSTALLED i 

+ — — — — — — — — — « — — — 

>08 1 LOAD ADDRESS I 

+ + 

>0A I I 

UNUSED (=0) 

I I 

* * 


>10 * maximum size 

Figure 11-7 Procedure/ Segment Description Entry 


Hex . 

Byte Description of Selected Fields 


>02 Flags, as follows: 

Bit Meaning When Set 


0 Unused (set to zero) 

1 System (segment only) 

2 Memory resident 

3 Delete protected 

4 Repllcatable (segment only) 

5 Share protected 

6 Unused (set to zero) 

7 Directory entry in use 

8 Unused (set to zero) 

9 Writable control store(WCS) 

10 Execute protected 

11 Write protected 

12 Updatable (segment only) 

13 Reusable (segment only) 

14 Copyable (segment only) 

15 Unused (set to zero) 

>04 Record number. Logical record number of the start 
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of the procedure Image In the program file. 
>06 Date Installed, In the following format: 

Bit Meaning 


0-6 Year (displacement) 

7-15 Jul lan date 

>08 Load address. Relative starting address within a 

mapped procedure segment. Must be on a beet boundary. 


Hex . 

Byte 

* * 

>00 1 LENGTH OF OVERLAY SEGMENT (BYTES) | 

H — — - — — _ — - — 

>02 I FLAGS I 

>04 1 RECORD NUMBER | 

+ + 

>06 I DATE INSTALLED | 

H — — — — — — — — — — — — _ — — — — — — — — — — — — — — — 

>08 I LOAD ADDRESS | 

+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + 

>0A I LINK TO NEXT OVERLAY | ID OF ASSOCIATED TASK | 

+ + + 

>0C I UNUSED (=0) I 

I I 

* * 


>10 * maximum size 


Figure 11-8 Overlay Description Entry 


Hex . 

Byte Description of Selected Fields 


>02 Flags, as follows: 

Bit Meaning When Set 


0 Relocation bit map Is present 

1-2 Unused (set to zero) 

3 Delete protected 

4-6 Unused (set to zero) 

7 Directory entry In use 

8-15 Unused (set to zero) 

>04 Record number. Logical record number of the starting 
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address of the overlay image in the program file. 
>06 Date Installed, in the following format: 

Bit Meaning 


0-6 Year (displacement) 

7-15 Julian date 

>08 Load address. Relative starting address within a 

mapped overlay segment. Must be on a beet boundary. 


11.4.5 Directory Files. 

Directory files are unblocked relative record files and have a 
record length of >86 or >100 characters. Record 0 of the 
directory file contains an overhead record. The remaining records 
in the file may contain one of the following types of data blocks: 

* File Descriptor Record (FDR) — Every file cataloged in 
the directory is represented by an FDR, which describes 
the file and its location on the disk. 

* Allas Descriptor Record (ADR) — Every alias of a file 
cataloged in the directory is represented by an ADR, 
which gives the location of the file and points to the 
FDR of the actual file. 

* Channel Descriptor Record (CDR) — Every channel that has 
an owner task in a program file in the directory is 
represented by a CDR, which describes the channel 
characteristics and identifies its owner task, 

* Key Descriptor Record (KDR) — Each key Indexed file 
cataloged in the directory is represented by an FDR, 
which in turn points to another record, the KDR. The KDR 
describes all of the keys (1 through 14) that are defined 
for the file. Note that the use of the KDR implies that 
each key Indexed file cataloged in a directory uses two 
directory entries. 

Figure 11-9 shows the general structure of a directory file. 
Entries are made by hashing the name of the file being entered. 
The hash algorithm results in a record number from 1 through n, 
where n is the last record in the directory file. Figure 11-10 
shows the hash algorithm. If the directory file record is unused, 
an FDR for the file being Inserted is placed in that record. If 
the record is already used, a free record is found by a linear 
search from the hashed record. 
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Figure 11-9 Directory File Structure 


PROCEDURE HASH (N : number of records In directory minus 1, 

NAME : name of the file being entered) 

BEGIN 
KEY : = 1 ; 

I := 1; 

C := NAME [ I ] ; 

WHILE CO'' AND I < 9 DO 
BEGIN 

KEY ;= ((KEY * C) MOD N) + 1 ; 

I := I + 1; 

C := NAME[ I] ; 

END 

END 


Figure 11-10 Computing a Hash Key 


If the file being Inserted Is a key Indexed file, another 
directory record must be found to contain the KDR. This record Is 
found by searching linearly from the FDR for the file. The KDR Is 
Inserted Into the first available directory record following the 
FDR. 

The different types of directory records are described In the 
following paragraphs. 

The directory overhead record (DOR), which Is record 0 of all 
directories, contains: 

* The maximum number of records (entries) In the directory 

* The number of currently defined files 
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* The number of available records (entries) 

* The file name of the directory 

* The level number of the directory In the disk hierarchy 
(VCATALOG) is level 0) 

* The file name of the parent directory 

* The default physical record length 

Each file cataloged under the directory Is represented by an FDR. 

Files can be given other names, each name being a separate alias. 
Each alias Is hashed to find an entry In the directory just like a 
file name, and an ADR Is Inserted in that entry. The ADR points 
to the actual file. It also points to the next alias for the 
file. 

Figure 11-11 shows a dump of the directory file .JB.DIR. The 
directory contains a sequential file ( . JB . DIR. SEQ ) , an Image file 
( . JB . DIR. IMAG) , a program file (. JB . DIR. PROG ) , and a key indexed 
file ( . JF . DIR. KIF) . The directory also contains an alias for the 
key Indexed file. The directory was created to have 11 entries in 
addition to record 0 which Is the DOR. 


11.4.6 Image Files. 

Image files are contiguous nonexpendable, unblocked relative 
record files that contain memory images of programs. They are not 
organized In any format; that Is, each sector of the Image file, 
starting with the first sector. Is completely filled with data. 
There are no overhead records or words. Image files are designed 
so that a program Image can be read Into memory In a single disk 
access . 


11.5 ALLOCATION OF SPACE FOR EXPANDABLE FILES 

When a file must be expanded, the amount allocated for the 
expansion depends on how much space is needed and where the space 
Is available on the disk. If there is a space available 
contiguous with the last allocation of the file, that space Is 
allocated for the expansion. In this case, the amount of space 
allocated may be less than that asked for by the file definition. 
If space Is not available contiguous with the current file 
allocation, one of two secondary allocations Is made. If a 
contiguous block is available with the size requested, that block 
is allocated. Otherwise, the largest available contiguous block 
of space Is allocated as the secondary allocation. 
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The amount of space asked for initially is the larger of 
SAS * (2 ** #SA) 

and 

TIMTBL( //EXT) converted to ADUs 

where : 

SAS is the defined secondary allocation size in ADUs 

//SA is the number of noncontiguous secondary allocations 

(ranging from 0 through 16) 

//EXT Is the number of file extensions, ranging from 0 through 
15, Initialized to // SA when a LUNO Is assigned 


TIMTBL(O) 

1 s 

1 

physical 

record 

TIMTBL( 1 ) 

Is 

2 

physical 

records 

TIMTBL( 2) 

1 s 

4 

physical 

records 

TIMTBLC 3) 

1 s 

8 

phy s leal 

records 

TIMTBL( 4) 

Is 

12 

phys leal 

records 

TIMTBLC 5) 

Is 

16 

physical 

records 

TIMTBLC 6) 

Is 

20 

phy s 1 cal 

records 


TIMTBL(7) through TIMTBL(15) are 24 physical records 

Each type of file can have secondary allocations. An Image In a 
program file can also have a secondary allocation. 
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FIlE access NAME; .JB.DIR 
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Figure 11-11 Dump of Directory File 
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11.6 IN-MEMORY DATA STRUCTURES 

The primary data structure used by file management during Its 
execution Is a record of the state of the request being processed, 
the File Manager work area (FWA). With each FM request, extra 
storage Is allocated for the FWA when the IRB Is processed by 
FMPREP. The extra storage Is required for the following 
Informs 1 1 on : 

* A workspace for execution 

* Information about the request Including block numbers, 
offsets, several fields of the FCB needed when the FCB Is 
not available, a description of the user buffer, a 
description of the blocking buffer, and vectors used to 
terminate processing at XOP level and reactivate at task 
level 

* A stack In which called routines save registers 


The part of the buffered request allocated for working storage Is 
pointed to by register 15 (R15), except In FMPREP and FMTASK, and 
Is addressed with the template FWA. The FWA Is detailed In the 
section on data structure pictures, as are the other In-memory 
structures . 

Other In-memory structures used by file management Include the 
f ol lowl ng : 

* File Control Block (FCB) - In-memory structure 
representing the last component of a file pathname, used 
to access the file for direct disk I/O In conjunction 
with the file directory block 

* File Directory Block (FDB) - Single node of the In-memory 
directory tree structure located In the file management 
table area. Provides tree linkage and Information needed 
to perform direct disk I/O to the file 

* File Descriptor Packet (FDP) - A two-word In-memory 
structure that Is used to access an FCB 

* Logical Device Table (LDT) - A description of the file 
resource. Including usage flags, ownership Information, 
parameters, and a pointer to the relevant FDP 

* Resource Privilege Block (RPB) - A structure used to 
control access privileges for resources 

Figure 11-12 shows the location and relationships between the 
various file structures maintained In memory In DNOS. 
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File Management Table Area 
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Figure 11-12 In-Memory File Representation 


File management routines fall Into the following categories: 

* XOP-level preprocessing 

* Task-level preprocessing 

* Address space management, including transfers between 
XOP-level and task-level code and the management of 
overlays 
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* Buffer management 

* Routines to perform file I/O operations (lODRCT) 

* Low-level routines that support I/O SVC sub-opcode 
processing 

File management code resides In four different areas. Some code 
Is found In the map 0 segment SVCSHD with other SVC processors, 
some Is In the variable part of the operating system root, some Is 
In the file management task segment, and some Is found In overlays 
on disk. 

Table 11-3 shows the major modules found In the file management 
source directory and where they fit Into the six major categories 
of routines. In addition to those listed, modules of stub 
routines are Included for those systems that do not support 
particular file management options. The names of these modules 
Include an S after the functional module name (for example, 
FMBKOFS Is the stub for FMBKOF). Stubs are found In modules 
FMBKOFS, FMCKEXS, FMFBSQS, FMOPSXS, FMRDBFS , FMRDUBS, FMRWSQS, 
FMSQORS, FMWRBFS, FMWRUBS , and KMBEGS. The last stub Is for 
systems that do not support KIF. 

Table 11-3 File Management Modules 

XOP-Level Preprocessing 

FMACTV Driver for opcode processors 

FMPREP XOP-level preprocessing - base routine 

Task-Level Preprocessing 

FMTASK Task-level driver 

Address and Overlay Management 

FMOVLO Overlay header tables, one for each overlay 

FMOVLl Overlay header tables, one for each overlay 

FM0VL2 Overlay header tables, one for each overlay 

FM0VL3 Overlay header tables, one for each overlay 

FMOVLYC Overlay code location tables - memory-resident 
sy s terns 

FMOVLYD Overlay code location tables - disk-resident 
systems 

FMPMGR Set of overlay pool management routines 

FMTRAN Transfer at XOP level between SVCSHD and FMTASK 

Buffer Management 

FMBIO Set of routines to buffer I/O and map blocked 

files 

FMCPB Copy buffer - blocked file 

FMCPBI Interface routine for FMCPB 
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Table 11-3 File Management Modules (Continued) 

I/O SVC Sub-opcode Processors 

FMCLEF Close with EOF processor 

FMCLOS Close operation processor 

FMFBSP Forward Space / Backspace operation processor 

FMFBSQ Forward Space / Backspace processor for 

sequential files 

FMOPEN Open operation processor 

FMOPRW Open Rewind operation processor 

FMOPSX Open Extend sequential file operation processor 

FMOPUB Unblocked Open operation processor 

FMOPXT Open Extend operation processor 

FMRDF Read operation processor 

FMRDUF Read Unblocked operation processor 

FMRWF Rewrite operation processor 

FMSQOR Open Rewind for sequential files 

FMLKUL Unlock operation processor 

FMWEOF Write with EOF operation processor 

FMWTF Write operation processor 

FMWTUF Write Unblocked operation processor 

Lower Level Support Routines 

FMBKAD File extension 

FMBKOF Block number computation 

FMBLAJ Blank adjustment 

FMBSRT Blank suppression routines 

FMCKEX Check file extension 

FMEXFL File extension 

FMMREC Compute ADU and sector from block number 

FMFIO Unblocked relative record I/O Interface to FMIO 

FMIO Read/write file block 

FMLKNF Lock operation processor; set of routines to 

check for locks; add them, and remove them 
FMLSET Creates LUNO for FMBIO on first buffer I/O 

of each FM task 

FMRDBR Read blocked relative record files 

FMRDSQ Read sequential file 

FMRDST Read file status 

FMRDUB Unblocked read of blocked files 

FMRWBC Rewrite blank compressed counter 

FMRWSQ Rewrite sequential file 

FMUPFD Update FDR 

FMUTLY Set of routines to check EOM; set 

parameters, and find structures 
FMWTBR Write blocked relative record file 

FMWTCK Check write privileges on a file 

FMWTSQ Write sequential files 

FMWTUB Unblocked write of a blocked file 
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To avoid the extra overhead required for preprocessing SVCs and 
I/O calls, a special Interface to I/O, FMIO, is used to perform 
file reads and writes. This same Interface Is used by the task 
loader to perform reads and writes to the swap file, and by lOU 
and the File Manager to update FDR records. The calling program 
obtains a block of STA sufficient to buffer the disk I/O call 
block and Initializes It as follows: 


BROOFL = 
BROBBA = 
BROLDT = 
BRORCB = 
BROTSB = 
BROJSB = 
BROBRO = 
IRBSOC = 
IRBOC = 
IRBSFL = 
IRBDBA = 
IRBICC = 
IRBOCC = 
IRBRNl = 
IRBRN2 = 


SMT address for segment containing buffer 
SSB address for segment containing buffer 
PDT address for device desired 
0 (supplied by lODRCT) 

EXTSB 

EXJSB 

0 

0 SVC opcode/error code 
09/0B subopcode/0 (no LUNO) 

0 system/user flags = 0 
offset Into buffer segment 
character count 
character count 

ADU of disk device to be read/written 
sector In ADU to be read/written 


The call block built Is passed to the direct I/O routine^ lODRCT . 
It then proceeds like an I/O SVC, but the overhead of SVC 
processing has been avoided. 


11.6.1 XOP-Level Preprocessing. 

FMPREP Initiates XOP~level preprocessing for the File Manager, and 
resides In SVCSHD. It takes the I/O call block buffered by lOPREP 
and creates the FWA needed by the File Manager to execute at XOP- 
level . 

The routines In FMTRAN (File Manager task call, FMTCAL, and File 
Manager task return, FMTRTN) change map file 0 to map In the File 
Manager task segment so that It can execute at XOP level. When 
XOP-level work completes, control Is transferred back to FMPREP; 
consequently, the map file must be changed to Its previous state. 
Some requests can complete execution at XOP level without changing 
to task-level code. The following conditions must be met for 
execution of a file management request to complete at XOP level; 
such execution Is referred to as fast transfer. 

* If the operation Is active (such as write, rewrite), no 
other operations are outstanding for the FOB; If the 
operation is passive (such as read), no active operation 
Is outstanding for the same FOB. 

* No requests are outstanding for the LUNO (that is, the 
initiate I/O count must be zero). 
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* The overlay area Is available when the opcode requires a 
system overlay. 

* If the operation Is Read or Write, the file Is a blocked 
file. 

* The LDT does not have the unblocked I/O flag set. 

* If the request Is a Write, the LDT does not have the 
forced. write bit set. 

* The required blocks are In memory. 

A file management request begins execution at XOP level. If a 
transfer to task-level code Is required, the routine FMTSET from 
module FMUTLY Is called. Such conditions can be detected at 
several points, both In FMACTV and In the operation processor. 
The following processing occurs at the level Indicated: 

1. (XOP) lOPREP sets the busy flag In the IRB prior to 
calling FMPREP. FMPREP passes control to FMACTV, which 
can call FMTSET to enter task mode. Other routines may 
also call FMTSET. 

2. (XOP) FMPREP sets up the vector In FWAXWP (in the FMT) 
such that a BLWP instruction transfers control to FMTRTN 
(In FMUTLY). 

3. (XOP) FMTSET checks to see If execution Is already In 

task mode. If so. It exits. If not. It executes a BLWP 
Instruction through FWAXWP (R15). The only purpose of 
the error Is to enable the caller to determine the 

previous execution mode* 

4. (XOP) The BLWP executed by FMTSET takes control to 

FMTRTN, which changes the map 0 file back to SVCSHD and 
branches Into FMPREP at label FMFXRT, which checks the 

busy flag In the IRB. If the flag Is clear, the request 

Is complete and the call block Is directly unbuffered. 
Initiate event flags are checked; If one Is set, the 
event Is marked In the TSB as completed. Upon 
completion of the unbuffering, FMFXRT returns via a 
branch to NFTRTN. 

5. (XOP) If the request Is not complete, the value In R14 
from the BLWP is stored In FWAPC (in the FWA). The busy 
flag Is still set, causing FMPREP to queue the operation 
for task-level file management and exit through lORTN. 

The busy flag causes lORTN to suspend the calling task 
(If this Is not Initiate I/O) and exit to the scheduler. 

6. (TASK) Eventually, either the scheduler chooses a file 
management task for execution (starting at FMTASK) , or a 
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file management task, already In execution dequeues the 
operation. If a buffer Is required, the segment of the 
user program containing the buffer Is also loaded. The 
JCA Is mapped In. 

7. (TASK) FMTASK puts the contents of FWAPC Into Its R14, 
computes the WP address In R13, and puts Its own status 
In R15. The FWAXWP and FWAXPC vector Is set up to point 
to FMP210 In FMTASK. An RTWP Is executed, thus resuming 
the activity In FMTSET Immediately following the BLWP 
that transferred control to FMTRTN. FMTSET sets no 
error and exl ts . 


11.6.2 Task-Level Processing. 

FMTASK is the driver routine that processes the start-up procedure 
and handles the processing between requests at task level. FMTASK 
is activated by the operating system queue server mechanism. When 
a file management task begins, the STA Is mapped Into the first 
segment, the user job JCA Into the second segment, and the file 
management code Into the third segment. FMTASK uses a workspace 
and stack that is allocated the first time the task Is bid. That 
workspace Is associated with the task, not with a BRB, and is used 
for the dequeuing and queuing calls and for acquiring the 
execution environment needed by the activity. FMTASK transfers 
execution to the point of suspension In XOP-level processing by 
activating the workspace In the BRB via an RTWP Instruction. 

File management overlays are read Into and executed In a pool of 
overlay areas allocated with the file management task segment. A 
set of subroutines Is used to transfer control between the file 
management root and an overlay. 


11.6.3 Flow of Control In File Management. 

Figure 11-13 shows the flow of control through the various parts 
of the file management processor and how a request Is handled. 
Each transition In the figure Is numbered. These numbered 
transitions are described In the list that follows. 


File I/O 


11-32 


2270512-9701 



DNOS System Design Document 


+ + 1 + + 2 + + 


lOPREP 1- 


— >1 

FMPREP 1 


>I 

fmtcal 

1 




1 

1 


+- 


+ 




1 

1 



1 3 





1 

1 



V 





1 

I +- 


“+ 6 +" 

— 

+ 




1 

1 1 

FMTSET 

l< 1 

FMACTV 

l< — 

— + 



1 

1 +■ 


-+<-+ +- 


+ 

• 



1 


1 

1 

* 4 


• 



1 

/ \ 1 

V 

1 

* 


• 

10 


YES 1 

/OP \ 1 9 +- 


-+ |7 

V 


• 

+ 

— 

— 

<COMPLETED>< | 

FMTRTN 

1 +-0P 

PR0CESS0R<- 

-+ 

1 


1 

\ ? /I +- 


-+<-+ 

* 


• 

UNBUFFERING 

1 

\ / 1 


1 

* 


• 

1 


1 

V 1 


1 

* 5 


• 

1 


1 

111 NO 1 


1 

V 


• 

V 


1 

1 1 


|8 +- 

— 

+ 

• 

+ 

-+ 

1 

QUEUE REQUEST! 


+— 1 

FMACTV 

1 

• 

1 NFTRTN 

1 

1 

TO FM QUEUE | 


+- 


+ 

• 

+ 

- + 

+ 

+ 



• 


• 




1 



. 14 

• 




V 12 



• 


• 




+ + + 

+ 


• 


« 




1 lORTN 1 1 

V 


• 


• 




+ + 1 


+ 13 

• 


• 




1 1 

1 FMTASK 1 

— 

— 

-+ 




V 1 

1 

1 

• 






+ + 1 

1 

1 

• 






1 NFSCHD 1 + 

1 

|< 

- — — — H 






+ + 

+ 






I 15 
NFEOR 
I 16 

— XOP Level V 

.. Task Level SVC 24 

** XOP or Task Level 


Figure 11-13 Flow of Control In File Management 


1. lOPREP buffers the call block, sets the busy flag In the 
IRB system flags field, and examines the LDT to 
determine the nature of the request. All extensions to 
the call block appropriate to the file type and access 
mode are buffered. Note that If the unblocked I/O flag 
Is on In the LDT, all files appear as relative record 
files and the call blocks are buffered accordingly. 
Control Is passed to FMPREP by a Branch Instruction. 
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2. FMPREP is contained in the SVCSHD segment, along with 
lOPREP, and continues running with the caller's JCA 
mapped into segment two. The context of the caller is 
saved in the TSB. A check is made to allow 
initialization on the first call (discussed below). 
Next, the I/O opcode is examined. If it requires a data 
buffer, the user's buffer is checked by calling RPSGCK. 
If the opcode is a read (of various forms), the 
protection of the buffer is also checked by calling 
RPPRCK. The file management activity record, the FWA, 
is Initialized with the stack pointer, FWA address, and 
IRB address. FWAXWP and FWAXPC are set up to transfer 
control to FMTRTN. A branch to FMTCAL is executed. 

3. FMTCAL (module FMTRAN) saves the third segment's limit 
and bias register values on the current stack, which is 
the scheduler stack. Then an LWPI instruction is 
executed to access the transition workspace, which is a 
partial workspace (contains RIO through R15) in FMTRAN 
used to manipulate the system map file 0 on the way to 
the workspace in the FWA. The third segment limit and 
bias are set to map in the file manager code segment. 
An RTWP instruction is executed which places execution 
control at the beginning of FMACTV . 


FMACTV locates the 

FCB 

and 

RPB 

and makes 

some 

preliminary 

checks 

to 

see 

that 

operation 

can be 

con t Inued 

at XOP level. 

If 

there 

is any 

active 

operation 

outstanding 

for 

the 

FCB , 

or if the 

current 

request is 

active and 

there 

1 s 

any 

passive operation 


outstanding for the FCB, FMACTV queues this request on 
FCBRLA queue and calls FMTSET. Processing continues at 
step 6. Otherwise, the opcode is decoded and the 
appropriate processor called. 

5. A processor is Included for each one of the file 
management I/O opcodes. Processing can continue at XOP 
level if the following three conditions are met: 

* A Write operation must not have the forced 
write bit set in the LDT 

* The file must be blocked 

* The block must be in memory 

Sequential files may be entirely or partially processed 
at XOP level. When a required block is not in memory, 
FMBRD calls FMTSET to transfer to task-level code. When 
the opcode processor completes, it returns to its 
caller, which is usually FMACTV. Exceptions are when 
FMWTF and FMFBSP are called for the Rewrite operation. 
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and when FMFBSP is called for the multirecord Read 
operation and for Open Extend on sequential files. 

6. At several points in processing the call, processing at 
XOP level can be Interrupted. This is denoted by 
transitions 6 and 7. Whenever this happens, the code 
call FMTSET, and FMTSET executes a BLWP through FWAXWP , 
which was set up in step 2 to transfer control to 
FMTRTN. 

7 . ( See step 8 . ) 

8. After completion at XOP level, FMACTV calls internal 
subroutine FMNEXT to dequeue appropriate number of 
requests from FCBRLA queue, and executes a BLWP through 
FWAXWP, which transfers control to FMTRTN. Processing 
completes through steps 9 and 10. 

9. FMTRTN (module FMTRAN) restores the map file to the 

point of the call to FMTCAL. It then branches to 

FMFXRT, an entry point in FMPREP . An Incomplete call 

causes processing to continue at step 11. 

10. The operation has been completed at XOP level and exits 
to lORTN. 

11. The operation has not been completed at XOP level. 
NFQUEH is called to queue the operation for task-level 
action; to exit, a branch is made to lORTN, lORTN 
handles Initiate I/O, and branches to the scheduler. 

12. Eventually, the scheduler chooses the activated file 
management task for execution. Control is passed to 
FMTASK, which is the task-level driver for file 
management requests that must complete at task level. 

13. FMTASK begins in a workspace and stack that is unique to 
the task. It dequeues the first request whose FWAQW is 
not set from JITFMQ. Using the state information in the 
FWA, it sets up the environment of the request by 
performing an SMLOAD call on the caller task segment if 
a buffer is required. The PC stored in FWAPC by FMPREP 
is placed in the FMTASK R14. FWAXWP and FWAXPC are set 
up to transfer control back to FMP210. An RTWP is 
executed, transferring control to the point in FMTSET 
after the BLWP, using the workspace and stack allocated 
with the BRB and begun in step 5. 

14. After completing an operation at task level, FMACTV 
executes a BLWP through FWAXWP, which FMTASK set up in 
step 13 to cause completion of the operation to return 
to FMTASK. 
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15. FMTASK queues the completed request for unbufferlng by 
calling NFEOR. 

16. If requests that need to be processed are queued to the 
request queue, file management continues processing. If 
JITFMQ has no more requests, an SVC >24 Is executed to 
await the next file management request. 


When file management takes end action, a system crash occurs with 
crash code >A0. This crash Indicates that file management 
encountered an error from which It could not recover. 


11.6.4 Overlay Management. 

File management overlays are used according to conventions similar 
to those used for system overlays. File management routines In 
overlays can be coded In one of two ways. 

* By using the conventions for standard subroutines. 
Register 11 and some other registers are pushed onto a 
stack upon entry, and these are popped from the stack 
upon exit. These routines can be called from Inside the 
overlay with FPRCAL. They can be entered from outside 
the overlay If a word pointing to the routine Is defined 
In the table at the beginning of the overlay. 

* By using a convention that allows routines to be entered 
only from outside the overlay. Nothing Is pushed onto a 
stack, and the exit Is a branch to FPORTN. The entry 
point for these routines must be defined In a word In a 
table at the beginning of the overlay. The entry point 
Is reached from Inside or outside the overlay by a call 
to FPOCAL. 

Both types of routines use FPRCAL to call routines In the resident 
root; the resident root may be either File Manager or the 
operating system. 

The routines for managing the overlay pool are found In the module 
FMPMGR. The following routines are Included: 

FPOCAL - Pooled Overlay Call 

Used to enter an overlay either from the root or from a 
different overlay. Any routine that has Its address defined 
In the table at the beginning of the overlay can be entered 
with this call . 

FPORTN - Returning From an Overlaid Routine 

Used to return from a routine In an overlay. It can be 
entered either directly or Indirectly. If the called routine 
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directly branches to FPORTN, It must return with the stack in 
the same form as upon entry to the called routine. 

FPRCAL - Overlay Pool Routine Caller 

Need arises frequently for routines that are overlay resident 
to call subroutines within the same overlay or within code 
resident outside the overlay structure. Such routines are 
called with FPRCAL. All subroutines called from within 
overlays must be called using either FPOCAL or FPRCAL. When 
FPRCAL enters a root subroutine, the overlay entry stack 
frame is built and Rll points to FPORTN. The normal NFPOP 
exit performed by such routines will cause exit to occur 
through FPORTN. 

FMEXFL - Extend File Processor 

One routine in an overlay, FMEXFL, must be exempt from the 
overlay rules. FMEXFL performs the extend file function. It 
must be callable from both the File Manager, which uses 
pooled overlays, and from the task loader, which does not. 
(The task loader uses FMEXFL to extend the roll file.) 
Hence, FMEXFL must never call anything that calls another 
overlay. FMEXFL calls certain root routines, but does so 
directly because it cannot assume the availability of the 
pool manager routines. An overlay area is not marked 
available until the calling task needs another overlay; 
consequently, the overlay area in which FMEXFL is executing 
is never marked available as long as it does not call 
anything that calls an overlay. 

An overlay area consists of enough reserved space for the largest 
overlay plus its relocation bit map, preceded by seven words of 
overhead, as shown in Figure 11-14. The first three words should 
be initialized to zero by the assembly and link process that 
creates the file management subsystem. They are initialized by 
the overlay load software the first time the overlay area is used. 
The SIZ field is initialized to the size in bytes of the COD area. 
OVN is initialized to -1 to flag that no overlay is in the area. 
USE is initialized to zero. OAD is set up to point to the next 
overlay area in the pool; OAD points to zero for the last overlay 
in the pool. COD is the area reserved for code. When an overlay 
is in use, the field FWAOAD points to OADCOD of the overlay area 
containing the code. 
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OADSMT 
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Figure 11-14 Overlay Area Structure 


Overlays are read Into an area obtained from a pool. The-^ pool Is 
a linked list of areas, and each area Is a piece of memory large 
enough for the largest File Manager overlay plus Its relocation 
bit map. When a new overlay Is entered (FPOCAL), a piece of STA 
Is obtained for the overlay to use for Its run-time stack. 
Whenever any routine call Is made to or from an overlay (FPOCAL or 
FPRCAL) , an overlay return frame Is built on the stack. 

Overlays are relocated at load time, eliminating the necessity for 
self-relocating code. The relocation algorithm relocates only 
those references that are within the address space of the overlay. 
Relocation requires that all return addresses that reference an 
overlay be made relative to the beginning of the overlay before 
being stored on the stack. 

When an overlay Is needed, a search Is made of all areas. If an 
area Is found with the desired overlay, the use count Is 
Incremented and the code Is entered. If an area Is not found, 
either of two paths are possible. In the first, the overlay Is 
loaded Into an area with a zero use count, and the code Is 
entered. The return code links any area whose use count goes to 
zero to the new end of the list; also, note that the search 
prefers the oldest available area. Consequently, tasks calling a 
second overlay tend to keep the first In memory. In the second 
path, no areas are available (nonzero use count) and the task must 
queue Itself to wait until an overlay area becomes available. 
Each time an overlay Is exited and the use count goes to zero, 
that overlay area Is linked onto the head of the overlay area 
list. Since the search for an available area proceeds from head 
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to tall of the list, preemption prefers the least recently used 
overlay areas • 

Whenever a call Is made to a routine via FPOCAL or FPRCAL, a two- 
word return frame Is built on the caller's stack. The first word 
pushed on the stack Is the return address made relative to the 
beginning of the overlay. This allows a preempted overlay to be 
reloaded Into a different overlay area, and the return addresses 
can be reblased to return to the proper code. The second word 
pushed on the stack Is the overlay Index from the contents of R9 
when the overlay was originally called. A call from the root 
produces a stack frame with the return address and -1 for the 
overlay number. The return logic recognizes the overlay number 
and marks FWAOAD with zero. Indicating no overlay; and FWAOAD 
activates a waiting task If the overlay area becomes available. 


11.6.5 Buffer Management. 

The buffer management module (FMBIO) contains routines used to 
access physical blocks of files. The routines are called from the 
modules that process blocked files: relative record, sequential, 
and key Indexed. Blocking buffers are mapped Into the middle 
segment. In place of the FMT, making It necessary for file 
management to copy parts of the FCB that must be accessed while a 
buffer Is being accessed. 

FMBRD - Reading a Block from Disk 

FMBRD checks the mode of execution. If In XOP mode, SMFSID 
Is called to determine whether the block Is In memory. If 
so, the block Is mapped Into the current map file 0, and the 
routine enters NRCOOO at label NRCOIG to complete processing. 
If the block Is not In memory, FMBRD transfers to task mode 
and calls FMBSEG. 

If FMBRD Is executing In task mode to begin with, the memory 
residence checked Is skipped and the routine calls FMBSEG. 
FMBSEG Is called from the entry point NRCOOO, an entry point 
that performs common processing for FMBRD and FMBNEW. NRCOOO 
obtains the flags from the OVB used to Initialize the File 
Manager flags In the FMT; these flags are used for buffer 
management operations. 

FMBSEG calls FMCHGS to get the buffer. The buffer Is 
obtained from memory (cached), from disk, or Is empty (If 
routine FMBNEW was called). FMCHGS first tries to get the 
buffer from memory. If the buffer Is not In memory. File 
Manager Is placed on the WOM queue. The task loader Is then 
responsible for loading the buffer from disk or for creating 
the empty segment . 

If execution Is In task mode, NRCOOO Inhibits the scheduler 
after obtaining the buffer segment. This routine Initializes 
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the FWA parameters that describe the block. Those parameters 
are used In the blocked record transfer, 

FMBNEW - Obtaining a Fresh Block 

FMBNEW always calls FMTSET at entry to guarantee task-level 
execution. Then, It enters NRCOOO to finish processing for 
the new block. It also calls an Internal entry, FMBCKS, to 
extend the file. If necessary, 

FMBW - Writing a Block to Disk 

FMBW always executes In task mode and processes an operation 
equivalent to a Forced Write Segment SVC, 

FMBREL - Releasing a Block After Use 

FMBREL returns a block to the cache list ready for future 
use. If the memory Is needed, the block can be released. 
The modified flag Is left In Its current state. The JCA Is 
mapped In to replace the block. In XOP level, special code 
sets the modified and releasable flags In the OVB. 

FMBRMD - Releasing a Block After Modification 

FMBRMD releases a modified block to the cache list. Marked 
modified, the block will be written before the memory Is 
released. This routine clears the not modified flag In the 
File Manager's segment flags and passes execution control to 
to FMBREL. 

FMBWRN - Rename and Write Block 

FMBWRN Is called by the KIF Manager to write a record to a 
new record position In a key Indexed file. FMBWRN modifies 
the buffer segment ID, writes the record to the new position, 
and restores the buffer segment ID to Its original value. 


11.6.6 Details of I/O Sub-Opcode Processors. 

The following paragraphs describe the processing of the operations 
of Read, Write, Close, Multiple-record Read, and Multiple-record 
Write for files . 

11.6.6.1 Re ad. 

FMRDF handles all requests for disk files (except requests for key 
Indexed files). FMRDF calls FMBKOF to compute the block number 
and offset and to place the results In the FWA. FMRDF calls 
CHKEOM to ensure that the desired record Is within the range of 
the file. Next, record locking Is checked. FMSETR is called to 
check for odd buffer addresses and record lengths. 

FMSETR places the minimum of the user-specified buffer length and 
the logical record size of the file Into R5 , and leaves the user- 
specified buffer length In RA , The values remain In these 
registers and are used by the blocked file handlers. Inside the 
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blocked file handlers, the value In R5 Is stored In the fourth 
word of the block specified for relative record files; R4 Is 
stored there for sequential files. Unblocked files are 

transferred to task level for processing, which occurs In FMRDF, 

11.6.6.2 Write . 

FMWTF processes all requests for writing to disk files (except 
requests for key Indexed files). FMWTCK Is called to determine 
whether the file Is write protected and whether the user has write 
privileges for the file. FMBKOF Is called to compute the block 
number, offset, and file part needed to satisfy the user's 
request. Next, the locked record chains are checked. If the 
record Is locked by another LUNO, an error Is returned. If the 
record Is locked by the requesting LUNO and the unlock bit In the 
BRB Is on, the record Is unlocked. Next, FMSETR Is called to set 
up the user buffer descriptor. In R5 It returns the the file 
logical record length or the user-specified buffer length, 
whichever Is smaller. It returns R4 as the user-specified buffer 
length. For relative record files, R5 Is used as the record 
length for writing. For sequential files, R4 Is used. When the 
user's request Is shorter than the logical record, the record Is 
zero-filled on the right. 

11.6.6.3 Close . 

The close function (FMCLOS) ensures that all modified blocks and 
the FDR are updated on disk. 

11.6.6.4 Multiple-Record Read. 

Multiple-record I/O Is supported to all file types except KIF. 

The format for multiple-record I/O Is as follows: the length of 
each Individual record Is stored In the word Immediately preceding 
the data. Odd-length records are supported; the record Is placed 
In the user buffer with the proceeding length word containing an 
odd number, but the next record begins on the next word boundary 
following the odd-length record. 

For a read, the user specifies In the read character count the 
total size In bytes of the space available for data. The system 
places records In the user's buffer, beginning with the length (In 
bytes) of the first record, followed by the record, followed by 
the length (In bytes) of the next record, and so on. Only whole 
records are transmitted. When the read completes, the output 
character count specifies the total buffer length In use. 
Including the length words preceding each data record. 

If an end-of-file record Is encountered and the read buffer 
contains at least one record, the end-of-flle flag is not set and 
the buffer Is returned to the user. The end-of-file flag Is set 
on the following read, and an empty buffer Is returned. 
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Blank adjustment Is Ignored on multiple-record reads. For 
example, If the record consists of 20 bytes, 20 bytes are read and 
the header word contains 20. If the file contains a record with 
80 bytes, of which the last 60 are blanks, 80 bytes are read. The 
padding that occurs when blank adjustment Is requested on a normal 
read Is not done on multiple-record reads. All multiple-record 
read logic Is contained In FMMRR. 

11.6.6.5 Multiple-Record Write. 

The user defines a buffer for a multiple-record write In the same 
format as created by a multiple-record read. Each record Is 
transmitted to the file In order of Increasing memory address. 
Blank adjustment Is honored on each record. Take care to ensure 
that the character count Is accurate. It must Include all header 
words and data. However, If the length of the last record Is odd, 
the character count may Include the byte following the proper end 
of the last record. All multiple-record write logic Is contained 
In FMWRW. 


11.6.7 Lower Level Support Routines. 

The following paragraphs describe the support routines for 
concatenated flies, unblocked relative record files, and blocked 
files. 


11.6.7.1 Concatenated Files and Multifile Sets. 

Concatenated file and multifile set handling Involves 
predominantly three routines: FMBKOF (for nonkeyed files), KMBEG 
(for key Indexed files), and FMBCLO (for both key Indexed and 
nonkeyed files). 

Unblocked Relative Record Files. 


FMBKOF Is called to map the logical record number to a block 
number and offset. For unblocked files, this consists of 
determining which part of the concatenation has the specified 
record. The logical record Is checked against the allocations of 
each file In the concatenation list. The correct FCB address Is 
placed In the FWA. The record number Is biased by the allocations 
of the preceding files, and the result Is stored In the FWA for 
use In direct disk I/O. 

Blocked Relative Record Files. 


FMBKOF checks the logical record number against the allocations of 
all files In the chain, and the FDP of the correct file is placed 
In the FWA. The logical record number Is then biased by 
subtracting the allocations of previous files, and the result Is 
used with the physical record length of the individual file to 
compute the block number and offset of the specified record. The 
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block number and offset are placed In the FWA. 
Sequential Files • 


FMBKOF uses the currency information in the RPB. The FCBs are 
scanned to find the file containing the current record. The 
appropriate FCB address is placed in the FWA, and the block number 
and offset are copied from the RPB to the FWA. 

Multifile KIF Sets . 

Multifile KIF sets are handled in KMBEG, in the KMRD routine. The 
block number desired is checked against the allocations of each of 
the files, and the FCB address of the correct one is placed in the 
FWA. The block number needed is biased by the allocations of the 
previous files to obtain a relative block number. 

Closing Blocked Files . 

To close a concatenated file, lOPREP closes the assigned LUNO. 
Then, file management completes the Close operation. FMCLOS calls 
FMBCLO to obtain all modified buffers written to the disk. FMBCLO 
calls SMFLSH and loops through each part of the concatenation to 
obtain all modified blocks written. 

11.6.7.2 Unblocked Relative Record Files. 

Records for unblocked relative record files are transferred 
directly to and from the user buffer. Each record begins on a 
sector boundary and occupies contiguous disk for the specified 
length of the logical record. File management must queue requests 
for unblocked files through task level. 

11.6.7.3 Blocked Files. 

Records for blocked files are transferred through an intermediate 
buffer allocated from free memory. The physical block on disk 
begins on a sector boundary and occupies contiguous disk for the 
specified length of the physical record. If the block size is 
larger than an ADU , only an integral number of blocks are placed 
in an ADU, and the first block must begin on the ADU boundary. 

Record Transfers. 


The transfer of the record from blocking buffer to user address 
space is handled in map 0 by routines called through NFMAPO . The 
routines used are NFCXFR, FMBSRD, and FMBSWT. The first one is 
used for relative record and unsuppressed sequential files. The 
other two are used for blank suppressed sequential files. FMBSRD 
unsuppresses from blocking buffer to user buffer, and FMBSWT 
suppresses from user buffer to blocking buffer. These routines 
are called by FMCPB, a routine in the root entered by the NFMAPO 
call. One of the parameters of the call is the address of the 
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transfer routine (one of the three routines listed above). The 
calling sequence to FMCPB Is set up by routines In FMCPBI , a 
module containing the routines FMCIRD and FMCIWT. These routines 
use the Information In the FWA, the user buffer descriptor, and 
the blocking buffer parameters to set up the call to FMCPB. 

Relative Record Files. 


FMRDBR Is the blocked relative record handler. It calls FMBRD to 
obtain the block. If the needed block Is not In memory, FMBRD 
calls FMTSET to obtain the block. The block, offset, and user 
buffer descriptor are then used In FMCIRD (module FMCPBI) to call 
FMCPB, which transfers the record. Blocked relative record files 
store data by the following algorithm. The block number Is 
determined by dividing the logical record number requested by the 
blocking factor. The quotient Is the block number. The remainder 
Is multiplied by the logical record size of the file to determine 
the byte offset Into the block at which the record Is found. 

Sequential Files . 


FMRDSQ Is the sequential file read handler. It calls FMBRD to 
obtain the blocks needed to process the request. If the block Is 
not In memory, FMBRD calls FMBSEG to execute the Change Segment 
SVC. As for relative record files, the block, offset and user 
buffer descriptor are passed to FMCPB via FMCIRD to transfer the 
record. For blank suppressed files, the address of the 
appropriate routine Is supplied In the calling sequence. 

Blank Adjustment . 

Blank adjustment on read Is performed after the record Is 
transferred to the user's buffer. Space left unfilled In the 
user's buffer after the read Is filled with blanks. This function 
Is selected by the blank adjust bit In the user's IRB. It Is 
performed by FMRDSQ. 

Blank adjustment on write Is performed before the record Is 
transferred to the blocking buffer. The length specified to be 
written Is used to find the end of the record In the user's 
buffer. Trailing blanks are counted, and only the characters up 
to and Including the last nonblank character are transferred to 
the blocking buffer. This function Is performed by FMWTSQ. 


11.7 KIF MANAGEMENT 

A set of routines used only for key Indexed files Is supplied. 
These routines, each having KM as the first two characters of Its 
name, should be thought of as a subsystem of file management. The 
buffer management routines of file management are used to perform 
low-level I/O functions. Eight system overlays are used by the 
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KIF manager to perform specific functions. 


When a user Issues a KIF request, control is passed to lOPREP from 
RPROOT, the SVC processor. lOPREP performs standard preprocessing 
and passes control to lOCHKX to finish preprocessing. In addition 
to performing the same functions as for other files, lOCHKX 
performs special processing for KIF, The key number Is validated 
to ensure that it is legal for the file. Space for an IRB and KIF 
currency block (KCB) is allocated. If currency is required, that 
Is, if the sub-opcode Is greater than >40, lOCHKX validates that 
the currency block Is contained in one map segment and that the 
segment Is not write protected. The currency block is then 
buffered into the STA, and control Is passed to FMPREP for further 
preprocessing. 

After determining the size of the largest key, FMPREP allocates 
enough space for a KIT, which contains a FWA, plus three times the 
sum of the largest key and six. The extra six bytes for each of 
the three keys is for overhead. Next, if a currency block is 
present and the currency block contains a valid key pointer, 
FMPREP validates that the key is contained in one map segment and 
copies the key into the first of the three key buffers at the end 
of the KIT. IRBFWA is set to point to the KIT, FMPREP then 
branches to FMTCAL, which causes FMACTV to be entered using the 
workspace in the KIT 


FMACTV transfers control directly to KMBEG, the main driver for 
the KIF subsystem. Control is passed to KMBEG with the address of 
the buffered request in register 12 (R12). The format of the 
complete buffered request is illustrated in Figure 11-15. 


+ + 

I BRO I 
+ + 

I : I 

+ + 

I IRBFWA I-— 

+ + 

I : I 

+ + 

I KCB 1 


1 / WORKSPACE FOR KIF (FWA) / 

I + + 

1 / WORKING STORAGE FOR KIF (FWA) / 

, + 

■+ / STACK SPACE FOR KIF (FWA) / 

-l — j- 

/ MORE WORKING STORAGE FOR KIF (KIT) / 

I (INCLUDES AREA FOR THREE BUFFERED | 

I KEYS AND OVERHEAD) | 

+ + 

Figure 11-15 Buffered KIF Request 


The FWA and KIT are always referenced using R15 as a base 
register; the BRO, IRB, and KCB are referenced using R12, 


11.7.1 KIF Data Structures. 

KIF routines use various data structures in addition to the 
structures used by the File Manager (that is, FCB, FDR, and FWA). 
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These structures are the B-Tree Block (BTB), KIF Currency Block 
(KCB), KIF Information Block (KIB), and KIF Task Area (KIT). Each 
of these Is shown In detail in the section on data structure 
pictures . 

B-Tree Block (BTB) 

The BTB is a disk-resident structure that contains the 
overhead for a key file. When a data record must be located, 
each level of the B-tree associated with the key is read in 
tree order to locate the record. KIF maps the BTB into its 
second map segment to access it. 

KIF Currency Block(KCB) 

The KCB is used by KIF to maintain currency for the user from 
operation to operation. When an operation is performed on a 
key file, the user's currency block is buffered into the STA 
along with the IRB. The KCB is shown in detail in Figure 
11-16. 

The first four bytes of the KCB. are defined in the DNOS SVC 
Reference Manual . Bytes 4 through 9 (a three-word entry) are 
the data block key for the data record. The first two words 
contain the block number for the current data record. The 
last word is the logical record ID for the current record. 
Bytes >A through >F are the B-tree pointer. The first two 
words contain the block number for the current B-tree entry. 
The last word is the address of the current B-tree entry when 
it is mapped into the KIF task (that is, the address when 
mapped into the second segment of the task). Bytes >10 and 
>11 are the size (in bytes) of this B-tree entry (that is, 
the size of the current key plus six bytes of overhead, 
rounded up to an even number). Byte >12 is used to store the 
last opcode used (for those operations that perform different 
functions depending on the last operation). 

KIF Information Block (KIB) 

The KIB is a disk-resident data structure. It contains data 
records for the file. 

KIF Task Area (KIT) 

The KIT is used by KIF as additional working storage. First, 
the KIT contains a FWA, which contains a workspace, stack and 
other data. Next, several fields of the FCB are buffered so 
that the FCB need not be mapped in when these fields are 
required. These fields are the file extent (or allocation) 
(FCBEXT), the block end-of-medl urn (FCBBKM), and the KIF 
extension to the FCB (Includes current command number, 
current log block, free block queue head, and the B-tree 
roots). Next, the KIT has pointers to the three key buffers 
that reside at the end of the KIT, the key number and size of 
the key being processed, and a B-tree stack used to contain 
the block number and B-tree entry address for each level of a 
B-tree. (This address is built when transversing down each 
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level of a B-tree searching for an entry. This allows 
tracing back up the B-tree to modify a higher-level entry.) 
Next, the KIT contains temporary storage for the KIF 
routines. Finally, the three key buffers reside at the end 
of the KIT. Each buffer contains room for the longest key 
plus six bytes of overhead. 

Dec . 

Byte 

A A 

0 I INFORMATIVE CODE | KEY NUMBER | 

A ____A 

2 I KEY VALUE POINTER | 

A A 

4 I DATA BLOCK RECORD NUMBER 1 DATA 

I I I BLOCK 

A A I key 

8 I LOGICAL RECORD ID VALUE | 

A — — — — — — — — — — — — — — — — — — — — — — ~ — — — — — — — — — — A 

10 I B-TREE LEAF NODE RECORD NUMBER ! 

I I I B-TREE 

A A [POINTER 

14 I MEMORY POSITION OF KEY VALUE IN B-TREE ENTRY j 

A — — A 

16 I B-TREE ENTRY SIZE j 

A~ — -.— — — — — — — — — ~ — — — — A 

18 [ LAST OPCODE USED | CURRENT OPCODE | 

A A 

Figure 11-16 KIF Currency Block 

Bytes (Dec) Field Use 


User-Supplied 

0 Used as an Input value when the partial key feature 

Is used. Used for set currency operations, read 
greater, and read greater or equal. Used as an 
output field for return of Informative codes under 
all circumstances 

1 For a key dependent operation, used as an Input value 

to specify the number of the key to be used, ranging 
from 1 through 14 

2-3 Address of the buffer containing the key to be used in 

a key dependent operation 

System -Defined 

4-7 Two-word number giving the physical record number of 
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the physical record that holds the logical record 
associated with the currency 

8-9 A number, unique within the physical record, associated 

with the logical record within the physical record 
that Is associated with the currency 
10-13 Two-word number of the physical record of the key 

Indexed file that holds the leaf node with the 
key associated with the currency 
14-15 Address of the currency related B-tree entry when the 

physical record containing the leaf node Is mapped 
Into the key Indexed file manager address space. 

A B-tree entry Is composed of a two-word physical 
record number, a logical record ID, and a key value 
16-17 The length of the key plus six 

18 Opcode of the last operation performed using this 

currency block. Read next and read previous 
operations check this value and If It Is equal to 
the set currency opcode, they perform a read current. 
Read previous also checks for the delete opcode. In 
which case a read current Is also performed. Other 
operations also use this field 

19 Current opcode 


11.7.2 KIF Management Code Structure. 

KMBEG Is the main driver for key Indexed file operations. It 
decodes the operation code and passes control to the processor for 
the specified operation. Table 11-4 lists the main processor for 
each operation. 


Table 11-4 KIF Main Routines 


Name 

Operation Performed 


KMCLOS 

Close (overlay residing In KMOPCL module) 


KMDEL 

Delete by Key and Delete by Current 
(overlay residing In KMDLSR module) 


KMINSR 

Insert (overlay) 


KMOPEN 

Open Random (overlay In KMOPCL module) 


KMRN 

Read Next 


KMRP 

Read Previous (contained In KMRN module) 


KMRR 

Read by Key, Read Current, Read by Primary 

Key 

KMRSQ 

Forward Space, Backspace, Read ASCII, Rewind 
(overlay In KMOPCL module) 

KMRW 

Rewrite (overlay) 


KMSC 

Set Currency Equal, Equal or Greater, and 
(overlay residing In KMDLSR module) 

Great e r 

The Read 

Greater and Read Greater or Equal operations 


performed by first calling KMSC, then KMRRC (entry point In KMRR). 
Several subroutines are used by KIF In addition to the buffer 
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management routines of File Manager. These are listed In Table 
11-5. 


Name 


Table 11-5 KIF Subroutines 
Function Performed 


KMBDEL 

KMBIN 

KMBS 

KMBSC 

KMBTD 

KMBTI 

KMBTIS 

KMBTS 

KMCNV 

KMEK 

KMGEB 

KMGFB 

KMKC 

KMKDG 

KMLOC 

KMLOG 

KMPLG 

KMRDK 

KMRWSO 

KMRWSl 

KMRWS2 

KMRWS 3 

KMRF 

KMSUK 

KMTAB 

KMULG 

KMWRN 


Modify higher level BTB (overlay) 

Search for key value In given BTB 
See KMBTS (entry point In KMBTS) 

Compute blank suppressed size 
Delete B-tree entry 

Insert entry Into specified B-tree 
Perform B-tree split (overlay) 

Search a key's B-tree for match on key value 
Convert character strings by country code 
Extract key from blank-suppressed file and unblank 
Get empty block for B-tree splits 
(entry point In KMGF) 

Get free block for record Insert or rewrite 
(entry point In KMGF) 

Compare two character strings of given size 
Find key descriptor entry, given key number 
Locate B-tree entry, given user currency 
Log current block 

Recover from an Insert error while In partial 
logging mode 

Read In data record by key 
Delete old key and Insert new key 
(overlay In KMRWS module) 

Get new block for record 
(overlay In KMRWS module) 

Map In new block and write out old 
(overlay In KMRWS module) 

Update B-trees for new record position 
(overlay In KMRWS module) 

Return block to free chain 
(entry point In KMGF) 

Compute key size and B-tree entry size 
Character conversion tables 
Unlog blocks to their position In file 
Force write a segment to a specified address 


11.7.3 Details of KIF Operations. 


Once File Manager has determined that an 
performed on a key Indexed file, control Is 
KMBEG buffers certain fields of the FCB 
validity of Input parameters, Initializes the 
KIT, and passes control to the processor 


operation Is being 
passed to KMBEG. 
Into the KIT, tests 
save area In the 
for the specified 
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operation. If an error Is encountered In the operation processor, 
control Is returned to KMERR (entry point in KMBEG) , which calls 
KMULG to unlog any records that have been logged , skips the 
unbufferlng of the KIT Into the FCB and returns control to the 
caller (with an error). If the operation completes with no 
errors, control is returned to KMCDN (entry point In KMBEG), which 
unbuffers the KIT Into the FCB and updates the FDR if the free 
chain has been modified and returns to the caller. 

11.7.3.1 Close. 

The Close operation is performed by KMCLOS. Record 0 Is updated 
by setting the log command number to 0 so that no unlogglng can 
occur on the subsequent open. Then, FMCLOS Is called to perform 
the close processing for a file. When control returns from 
FMCLOS, the Close operation is complete. 

11.7.3.2 Open Random. 

The Open operation Is performed by KMOPEN. FMOPEN Is called to 
open the file. Upon return from FMOPEN, KMOPEN calls KMULG If 
there are no other LUNOs open to the file. FMOPEN does not use 
the currency block, 

11.7.3.3 Read Greater and Read Greater or Equal, 

These operations are handled by two separate processors. First, 
KMSC Is called to establish the currency for the subsequent read 
operation. KMSC calls KMBTS to search the B-tree of the specified 
key for a matching key value; If no match Is found, KMBTS searches 
the first B-tree entry with a key of greater value. If no match 
exists, an Informative code Is returned to the caller. Otherwise, 
KMSC returns to KMBEG, which calls KMRRC to process the Read 
operation. If the file Is single keyed, KMLOC is called to read 
the B-tree record described by the currency set up by KMSC, This 
Is required since the key value Is blanked out in the data block 
and therefore must be obtained from the B-tree block. 

Next, KMRRC calls KMRDK to read the data block to which the 
currency block points. The data block Is moved to the user's 
buffer via the FMCIRD routine. If the file Is single keyed, the 
key value Is moved Into the user's record. Finally, record 
locking, if specified. Is accomplished by the FMLKCK and FMLKON 
routines . 

11.7.3.4 Read by Key, Read Current, and Read by Primary Key, 

The Read Current operation Is processed the same as the Read 
Greater operation except that the KMSC step is eliminated (since 
the currency Is already set.) The Read by Key and Read by Primary 
Key operations are also processed like the Read Greater operation 
except that the currency must be set before control is turned over 
to KMRRC. The currency Is set In KMRR by calling KMBTS to search 
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the B-trees to find the block holding the specified key* If the 
block is found, the currency is established and control is passed 
to the KMRRC routine. 

11.7.3.5 Read Next. 

The Read Next operation is performed by KMRN . KMLOC is called to 
locate the next entry from the current entry set up by a previous 
operation. If such an entry Is found, the Read Random (KMRR) code 
Is entered at entry point KMRRB. KMRRB reads the data block, 
moves the record to the user's buffer, and moves In the key value 
(If the file Is single keyed). 

11.7.3.6 Read Previous. 

The Read Previous operation Is performed by KMRP (entry point In 
KMRN module). This operation Is Identical to the Read Next 
operation except that KMLOC is called to locate the entry that 
precedes the current one. 

11.7.3.7 Insert * 

The Insert operation is performed by KMINSR. KMINSR first checks 
to see If the file Is single keyed. If so, the key value Is 
blanked In the user's buffer (Note: The key value Is not 
duplicated in the data block, thereby freeing disk space.) KMBSC 
is called to compute the blank-suppressed size of the user's 
record. If the size Is greater than the physical record size of 
the file, an error is returned to the caller. (Before the error 
is returned, the key is restored to the caller If the file Is 
single keyed.) KMGFB Is called to find a free block with enough 
space to hold the blank-suppressed data record. The record number 
of this block Is stored In the currency block, and the user's data 
record Is transferred to It via the FMCIWT routine. Once 
completed, the data record Is written and the key value Is 
restored to the user's buffer. 

Now that the data record Is In the data block, an Insert Into the 
B-tree Is required for each key of the record. KMBTS Is called to 
search the B-tree of the key for a matching key value. If no 
match Is found, KMBTS searches for the first entry with a greater 
key value. If a match exists, a check is made to see If 
duplicates are allowed on the key. If not, an Informative code is 
returned to the user. Next, KMBTI Is called to Insert the entry 
Into the B-tree for the key. This sequence Is followed for each 
key. The end-of -me di um record number Is incremented, and a flag 
Is set to Inform KMBEG that the FDR must be updated. 

When the partial logging bit is set in the primary key flag word 
of the KDB, KMINSR force writes the data block and defers the 
writing of all other blocks. If an error occurs after the first 
key Insert and before the last, an error recovery overlay Is 
loaded. The error recovery overlay (KMPLG) uses KMBTD to delete 
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the data record from the data block and deletes the keys which 
were just Inserted. This allows the capability of unlogglng an 
Insert while taking advantage of i)uffer caching to Increase the 
speed of an Insert. 

11.7.3.8 Rewrite. 

The Rewrite operation is performe<l by KMRW. First, KMRW checks to 
see If the file Is single keyed; ; f so, KMRW blanks out the key In 
the user's buffer. (Refer to the description of this function In 
the paragraph on Insert.) A checl: is made to ensure that the 
record size Is less than the )hysical record size of the file. 
The key Is then replaced in the uuer's buffer (If single keyed). 
Next, if the file Is single keyed, KMLOC is called to obtain the 
key value for the key specified bv currency. KMRDK is called to 
read the block that contains the old record, and a check Is made 
to determine If the new record will fit In the old record. If 
not, the old record is prelogged by KMLOG, and the overlay KMRWSl 
is called to obtain a new block to hold the record. 

KMEK is called to copy the old key into the second key buffer (In 
KIT), and the user's key Is copied Into the first key buffer. 
KMKC Is called to compare the val les of both keys. If the values 
are different, a check is made to ensure that the key is 
modifiable. If not, an error Is returned to the caller. However, 
If the key value Is different an i the key Is modifiable, the 
KMRWSO overlay is called to delete the old key value and Insert 
the new. If more keys exist for rhe file, the key values are 
updated for each one. 

Once the key values are updatJd, the new record must be placed 
Into the appropriate block. This Is accomplished by first seeing 
If the new record is the same siz 2 as the old record. If not, the 
old record space is removed from Its block. If the new record Is 
smaller than the old record. It I 3 Inserted into the old block. 
If the new record is larger, the iCMRWS2 overlay Is called to write 
out the old block and map In tie new block, which was retrieved 
earlier in a call to KMRWSl. Flnilly, the new record is moved 
Into the block by FMCIWT. (If the file is single keyed, the key 
value is blanked out.) The data block Is written; If a new block 
was used for the data record, the KMRWS3 overlay is called to 
update the B-tree for the ne v location. If unlocking was 
specified, FMLKOF is called to turn off locking on the record. 

11.7.3.9 Delete by Key and Deleta by Current. 

The Delete by Key and Delete by Current operations are performed 
by KMDEL. If Delete by Key was requested, the currency Is set up 
by a call to KMBTS. KMLOC is called to read the BTB described by 
the user's currency in order to locate the data record for the 
key. A check is made to ensure that the record being deleted Is 
not locked. KMRDK is called to read the data record described by 
currency. The key value is copied into a buffer (by KMEK). For 
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each key of the file, KMBTD Is called to perform the delete. 
After the key Is deleted, the data record Is deleted. This Is 
achieved by first prelogging the data block, then moving up each 
entry below the entry to be deleted. The block Is then linked to 
the free chain, If It Is not already there, by calling KMRF. The 
data block Is written to Its file position, and currency Is 
modified to point to the preceded entry In the data block. The 
end -of -me dl urn record number Is decremented, and a flag Is set to 
Inform KMBEG that the FDR must bje updated. 

11.7.3.10 Set Currency Equal, Greater, Equal or Greater. 

The Set Currency Equal, Set Currency Greater, and Set Currency 
Equal or Greater Is performed by the KMDLSR overlay. If a Set 
Currency Greater Is executed, a value of 1 Is added to the last 
byte of the key In order to get the next greater entry. KMBTS Is 
called to perform the B-tree search for the specified key. If a 
unique match Is found, the B-tree and data block currency are set 
to point to the specified key. If a match Is found with 
duplicates, an Informative code Is returned to the caller and 
currency Is set up. If a match Is not found and a Set Currency 
Equal was executed, an Informative error Is returned without 
currency being set. Otherwise, currency Is set to the next 
greater entry than the specified key. Upon exit, a check Is made 
to determine whether the record Is locked; If It Is, an 
Informative code Is returned. 

11.7.3.11 Forward Space, Backspace, Read ASCII, Rewind. 

The Forward Space, Backspace, read ASCII, and Rewind operations 
are performed In KMRSQ. Each of these operations stores currency 
Into the last five words of the RPB. To make six words of 
currency fit Into five words, the first byte of the data base key 
and the B-tree pointer physical record numbers Is not stored. 
This fact causes no trouble, however, since a file cannot be large 
enough to use these bytes. If a Rewind operation Is performed, 
the currency In the RPB Is simply zeroed. KMRSQ executes Forward 
Space and Backspace operations by making repeated calls to KMLOC, 
which locates either the Immediately preceding or the Immediately 
following record and sets the KCB to the currency of the record 
found. KMRSQ calls KMLOC the number of times specified by the 
IRBOCC field of the call block. After the last call, It copies 
the currency In the KCB to the RPB. For a Read ASCII operation, 
KMRSQ calls KMLOC one time to locate the next record and moves the 
currency from the KCB to the RPB. KMBEG will then call KMRRC to 
actually read the record. 
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11.7.4 Details of KIF Subroutines. 


KMBDEL 

This routine Is an overlay called by KMBTD whenever a B-tree 
entry of the greatest value Is deleted. The next-higher- 
level B-tree must be modified as follows to reflect the new 
greatest value. First, the new highest key value Is copied 
Into the first key buffer for later use. The lower-level 
block Is written back to the file, with the B-tree entry of 
greatest value deleted. If this was the last entry In the 
block. It Is returned to the free chain by calling KMRF. 
When the block Is returned to the free chain, the predecessor 
and successor must be linked. Once the lower-level block Is 
released, the higher-level block Is read. Before modifying 
the higher-level block, the block Is prelogged by calling 
KMLOG. Then, If the lower-level block Is not empty, the new 
greatest key value Is moved Into the higher-level block. If 
the new key value Is also the greatest key value In the 
higher-level block, the next-hlgher-leve 1 B-tree must also be 
modified. If the lower-level block Is empty, the B-tree 
entry for the block Is deleted; KMBDEL Is reentered If either 
the greatest entry or the last entry was removed. Upon exit 
the higher-level block Is written back to the file. 


KMBIN 

KMBIN Is called to perform a binary search for a given key 
value within a given B-tree block. This routine receives a 
pointer to the key value. The B-tree block which Is to be 
searched Is mapped In, and R5 Is set to point to the B-tree 
block. KMKC Is called to determine In which half of the 
partition the key resides. The partition Is halved until It 
converges, and KMKC Is called to set up the comparison 
results for output. 


KMBSC 

KMBSC Is called to compute the number of characters that a 
field would have If It were blank suppressed. A pointer to 
the field and the number of characters Is Input. This 
routine simply computes the number of nonblank characters and 
Includes the blank-suppression overhead word where needed. 


KMBTD 

KMBTD Is called to delete a B-tree entry. First, KMBS (an 
entry point In KMBTS) Is called to search the B-tree with the 
given key value. If the entry Is not found, KMBTD Is exited. 
Otherwise, the B-tree record is read, and the entry Is 
located In the block. The BTB Is prelogged by KMLOG; If this 
key Is the one specified by the currency block, the currency 
Information Is updated to print the preceding B-tree entry. 
The entry is deleted by moving up all entries below It In the 


File I/O 


11-54 


2270512-9701 



DNOS System Design Document 


BTB. If the block Is now empty and the key was the one 
specified by currency, currency is set up to point to the 
predecessor BTB. If the greatest key in the block was 
deleted, the KMBDEL overlay is invoked to modify the higher- 
level B-tree structure. 


KMBTI 

KMBTI is called to Insert an entry into the B-tree associated 
with the key specified by the caller. The specified BTB is 
read and its image is prelogged by KMLOG. If the BTB cannot 
accommodate the size of the new entry, the block must be 
split by the KMBTIS overlay. Once a block large enough for 
the new entry is received, the entry is placed in the block. 
It may be necessary to move some of the entries in the block 
down in order to Insert the new entry in its required 
location. The B-tree overhead is updated, and the block is 
written to its file position. 

KMBTIS 

KMBTIS is called to perform a B-tree split for KMBTI. A 
descriptor of the B-tree to be split is input. Figure 11-17 
and Figure 11-18 Illustrate how the B-tree looks before and 
after a split. Note that in Figure 11-17 the root is 
splitting, whereas in Figure 11-18 a regular B-tree node is 
splitting. 

Before Split * * 

I root I 

* — — — 

After Root Splits 

* it 

I root I (modified) 

* * 


I new 

i: — ~^ic 

(left I B-tree | 
block) I entries | 


I new 

* * 

> I B-tree | ( r 1 gh t 

< I entries | block) 

* — — — * 


Figure 11-17 Example of Root Node Split 
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Before Split 


* * 

I root I 

* * 


I A 


* 


* 


|B 


■k 


* 


I B-tree | 
I entries | 

k — — — 


I B-tree | 

I entries | 
k * 


After Right 
(Block B) 
BTB Splits 


* * 

I root I 

* * 


1 A( mo 

dlf led) 

4 4 * 

1 new 

if - 

1 B (mo 

dlf led) 

k 

B-tree 

I-> 1 B-tree | -> 

1 

B-tree 

1 

entries 

1 <-| entries 1 

<-i 

entries 

1 


* * 




k 


Figure 11-18 Example of Regular B-Tree Node Split 


First, an empty block is retrieved by calling KMGEB (an entry 
point in KMGF), This block is used for the left BTB. If the 
B-tree root ( 1 owe s t -le ve 1 BTB) is being split, another empty 
block is retrieved to hold the right BTB. The block that 
needs to be split is read, and the last entry is copied into 
the second key buffer. The new entry is inserted into the 
data block, which may require moving down other entries. 
Next, a check is made to determine whether the block should 
be split 50/50 or 90/10. If records are inserted 
sequentially into the B-tree, the new left block contains 90 
percent of the entries, and the new right block contains 10 
percent of the entries. Thus, if the user continues to 
insert sequentially, the next B-tree split will be delayed. 

Depending on the split ratio, the number of entries to use in 
the left block is calculated and the block overhead is 
updated to reflect the number of B-tree entries and the 
amount of free space. The successor and predecessor pointers 
are set up, the new block number is updated, and the new left 
block is written to the file. The greatest key value in the 
left block is saved in the first key buffer for later 
insertion into the higher-level BTB. 

Next, the right block is set up by determining the number of 
entries in it, moving the B-tree entries up to the top of the 
block, and restoring the last (greatest) entry to the block 
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(saved in the first key buffer at the start). The pointer 
fields are set up, and entries are defined for the space 
remaining and the number of entries in use. If the root is 
split, the new right block number is stored in the block and 
the block is written to its new file position. A new root 
block is created, and the two new greatest entries are stored 
in the root. If the root is not being split, the right block 
is written to its original file position and the original 
block's predecessor block has its successor pointer modified 
to point to the new left block (via the FXPPTR subroutine in 
KMBTIS) . 

KMBTS 

KMBTS is called to search a given key's B-tree for a matching 
key value. If no match is found, KMBTS searches the first B- 
tree entry with a key value greater than that specified. 
This routine also builds a B-tree stack (saved in KIT) that 
contains three words (block number and index) for each B-tree 
level. Each level of the key's B-tree is read, beginning 
with the root. KMBIN is called to find the matching key 
value or the next greater value for each B-tree. If a match 
is found, a check is made for a duplicate entry. If a 
duplicate entry is found, an output flag is set accordingly. 
If duplicates exist, the B-tree stack will be set up to point 
to the last duplicate. The B-tree is read and the B-tree 
stack is updated for each level until the leaf node is 
reached. If the specified key value matches the last entry 
of a block, the successor block is read to determine if a 
duplicate exists in it. If a duplicate does exist, the above 
process is repeated until the last duplicate is found (many 
successors may be read). The B-tree stack is set to the 
record that contains the last duplicate. Once the leaf node 
is reached, the output flags are initialized for duplicates 
and unique match. 


KMCNV 

KMCNV is called to convert strings, using the country 
conversion tables set up by KMBEG. 


KMEK 

KMEK is called to extract a key from a blank-suppressed file, 
unblank it, and move it to a buffer specified upon Input. 
First, KMKDG is called to find the key descriptor for the 
specified key. The key size and offset into the record can 
be determined from the key descriptor. If the file is single 
keyed, the key value is taken from the first key buffer 
(which was set up by File Manager) and KMEK is exited. For 
multi-key files, the key must be unblanked by KMEK rather 
than by File Manager. 


KMGEB 

KMGEB is called to obtain an empty block for B-tree splits. 
The file end-of-medi urn is advanced, and FMCKEX is called to 
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check the file extension. If necessary, the file will be 
extended , 


KMGFB 

KMGFB Is called to obtain a free block with adequate space to 
accommodate a record that Is being Inserted or rewritten. 
First, KMGFB checks the free chain pointer In the KIT to 
determine If there are any free blocks. If not, the end-of- 
medlum of the file Is incremented and a new block Is read in. 
The overhead of the block is Initialized (block number, space 
remaining, and free chain pointer), and this block is 
returned. If free blocks are available, the first one Is 
read, prelogged by KMLOG,. and a check Is made to determine if 
it has enough free space to accommodate the record. If the 
space Is sufficient, this block is returned to the caller. 
If the space Is Insufficient, the block Is removed from the 
free chain (the free block pointer In the block Is set to the 
value negative 1) and written to the file. The next free 
chain block Is then tried. If a large enough block of free 
space has not been found after three tries, the new block Is 
taken from the end-of-medlum. 


KMKC 

KMKC Is called to perform a logical comparison on two 
character strings. If the two strings are ASCII, the result 
corresponds to the ASCII sort order. If the strings are of 
different lengths, the longer string Is truncated and 
ignored. KMCNV Is called to perform any conversion on 
international text. 


KMKDG 

KMKDG Is called to find the key descriptor entry (located In 
KIT) with a given key number. 


KMLOC 

KMLOC Is called to read a B-tree record and locate the unique 
entry described by currency. The caller may specify the 
current entry, the prevlous-to- current entry, or the 
successor to the current entry. KMLOC starts by reading the 
B-tree record contained in the currency block. The address 
of the B-tree entry described by currency Is located In the 
currency block (the third word of the B-tree pointer). If 
this address Is zero, either of two situations can result. 
If the prevl ous-t o-current entry Is needed, the predecessor 
block Is read to find the entry. If no predecessor exists, 
an Informative code Is returned. If the successor to the 
current entry or the current entry Is desired, the first 
entry In the BTB is used. When the address of the current B- 
tree entry is non-zero, a check Is made to see If this B-tree 
address points to the data block In the currency. If not, 
the correct B-tree entry is found by searching through the B- 
tree. Once the B-tree entry that points to the correct data 
block Is found, the currency Is modified according to what 
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was requested ( previ ous-t o-cur rent , current, or successor-t o- 
current). When a single-keyed file is used, the key value is 
copied into the first key buffer. 

KMLOG 

KMLOG is called to prelog the block currently mapped by the 
caller. The position in the log records to which the block 
should be written is kept in the KIT (KITCLB). Also, the log 
command number for the logging is kept in the KIT (KITCMD). 
Blocks will not be logged if the force write flag is turned 
off (that is, a Modify Key File Logging (MKL) command was 
executed). 


KMPLG 

KMPLG is called from the Insert overlay (KMINSR) to recover 
from selected insert errors while a file is set to partial 
logging. KMPLG recovers from Insert errors by simulating the 
roll back action of KMULG. Any keys inserted by the current 
Insert operation are deleted using KMBTD. The data record 
from the current Insert is deleted from the data block. No 
errors are returned by KMPLG. 


KMRDK 

KMRDK is called to read a data record with a given data base 
key. The data base key consists of a block number and key 
ID. The record is read in an attempt to locate the specified 
key ID. If the ID is found, the address of the entry is 
returned. If it is not found, a zero is returned for the 
address . 

KMRWSO 

KMRWSO is called by the Rewrite processor ( KMRW ) to delete an 
old key and insert a new key. The old key is passed in the 
second key buffer, while the new key is in the first key 
buffer. First, a check is made to see if an old key exists. 
If a >FF resides in the first byte of the key or the key is 
blank, the key does not exist. If an old key does exist, it 
is deleted by the KMBTD routine. 

The new key is now Inserted into the B-tree. Again, if a >FF 
resides in the first byte of the key or the key is blanked, 
the Insert is not performed. If a new key exists, KMBTS is 
called to search the B-tree for the specified key. If a 
matching key value is found, a check is made to ensure that 
duplicates are allowed. KMBTI is called to Insert the new 
key into the B-tree. If this key was the currency key, the 
user's currency is set up to point to the new Insert B-tree 
entry . 

KMRWS 1 

KMRWSl is called by the Rewrite processor (KMRW) to obtain a 
new block for a data record, KMGFB is called to return a 
free block, A new key ID is generated for the record, given 
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the current maximum key ID used. Also, the address where the 
new record will reside is computed. 

KMRWS2 

KMRWS2 is called by the Rewrite processor (KMRW) to map in a 
new block and write out the old block. This routine writes 
the block currently mapped, reads the new data block, 
increments the highest key ID used in the block, and sets up 
the currency for the new block. 

KMRWS3 

KMRWS3 is called by the Rewrite processor (KMRW) to update B- 
trees when a data record moves. For each key of the file, 
the key value is located (if it exists), and the BTBs are 
searched by KMBTS to find the entry for the key. The block 
returned by KMBTS is read and searched for the location of 
the key. When the key that has the same data base ID (that 
is, pointer to data record) as the old record is found, the 
new data base ID is stored in the B-tree entry. 


KMRF 

KMRF is called to return a block to the free chain. The 
block is simply linked to the free chain and written back to 
the file. 


KMSUK 

KMSUK is called to compute the key size and B-tree entry size 
given the key number. This routine passes a key number to 
KMKDG, which returns the key descriptor entry containing the 
key size. The B-tree entry size is the key size plus six. 


KMTAB 

KMTAB contains conversion tables used to convert standard 
ASCII characters into a nonstandard collating sequence. 


KMULG 

KMULG is called to write preimages logged at the beginning of 
the file (in the preimage log area) to their true positions 
in the file. This routine is called whenever an Open is 
executed (to clean up operations only partially completed) 
and whenever an error occurs in an operation. If the Open 
routine calls KMULG, unlogglng begins at record 0. If the 
command number in the block is zero, unlogging does not 
occur. 


KMWRN 

KMWRN is called to force write a buffer segment to a 
specified address. This routine temporarily modifies the 
Installed ID in the SSB of the buffer segment mapped into 
position two and sets the modified flag. FMBW is then 
called. After the buffer has been written to the file, the 
SSB is restored to its original state. 
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SECTION 12 
DNOS SYSTEM TASKS 


12.1 SYSTEM TASK ENVIRONMENT AND CONVENTIONS 

A system task executes with the following segments mapped In by 
map file 1: the system root, the JCA of the executing job, and 
the task code. Tasks that run under the system job have the 
system JCA mapped In. System tasks may need to map out the 
system JCA and map In another table area using the set of nucleus 
routines described In a previous section. 

A system task that runs in a user job has the user JCA mapped In 
as its second segment of map file 1. If the task is a system 
queue server, it has a queue header in the user JCA. RPROOT 
examines flags in the request definition block (RDB) for an SVC 
to determine whether or not the server is to be bid in the user's 
job. If so, RPROOT calls NFQUEH to queue the request to the 
appropriate queue header in the user's JCA and to bid the server 
task in the user's job. The queue server is bid with its second 
parameter being the queue header address. Using this address, 
the queue server can process its requests and terminate when the 
queue is empty. 

All routines in the system root can be directly accessed by 
system tasks. In addition, a system task can transfer into map 
file 0 to use routines in map file 0 or to do work that cannot be 
done in map file 1. The nucleus function NFMAPO is used to 
access map file 0 code; NFMAPO is described in the section on 
nucleus functions. 

A system task has access to data structures as well as common 

operating system routines in the system root. The available 
structures Include queue headers, global pointers, global data, 
and any other structure located in the system table area. 


12.2 WRITING AND LINKING AN ASSEMBLY LANGUAGE TASK 

System tasks should follow the conventions used for DNOS code 
(see the section on naming and coding conventions). 

The link of a system task needs to Include the system root. The 
link control file shown in Figure 12-1 shows an example, where 
the object code for the task is in the file PROG . TASK . OB JE CT . 
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VOLOBJ Is the volume name of the disk on which the linkable DNOS 
code resides (that Is, the response to the DATA DISK prompted 
during system generation). 


NOPAGE 

ERROR 

PROCEDURE DUMROOT 
DUMMY 

INCLUDE VOLOBJ. S$SGU$ .DUMROOT 

PHASE 0, NEWTASK,PROG >C000 
INCLUDE PROG. TASK. OBJECT 
END 


Figure 12-1 Example of Link Control for System Task 


12.3 USING OVERLAYS IN ASSEMBLY LANGUAGE SYSTEM TASKS 

System overlays are overlays of system tasks that have an entry 
In a table built during system generation to enable loading In 
one disk access. They are used In the following subsystems: 
file management, key Indexed file management, disk management, 
the I/O Utility, and error processing for program management. 
Such tasks must reside on the kernel program file and sysgen must 
be aware of the overlays In order to build appropriate 
1 Inks t reams . 

System tasks may also use standard user overlays. User overlays 
require no knowledge by system generation. 


12.3.1 Overlay Data Structures. 

The data structures used to support system overlays are shown In 
detail In the section on data structure pictures. The following 
paragraphs describe the major aspects of the structures used. 

OAD - Overlay Area Descriptor 

The OAD Is a block of OADSZ bytes of storage Immediately 
preceding the overlay area start address. The OAD Includes 
Information needed by the overlay loader: size of overlay, 
overlay number, use count, and link to the next overlay 
area. These pieces of data must be initialized by the 
subsystem planning to use the overlay. (The link and use 
count words are needed only for pooled overlays.) The size 
is the size In bytes of the area available for reading the 
Image and relocation bit map. If the overlays are never to 
be relocated, the size does not have to include space for 
the relocation bit map. The overlay number should be 
Initialized to -1. Immediately following the link word 
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OADSIZ bytes are reserved for the overlay area Itself. 

OVT - Overlay Disk Location Table 

The OVT is a table in the system root that contains the disk 
locations and other pertinent Information for system 

overlays. The copy module SOV contains Indexes into this 
table for the information on each overlay. The table is as 
f ol lows : 

SOVT EQU $ 

El DATA OVTREC,OVTSIZ,OVTLOD 

E2 DATA 0,0,0 


where : 

OVTREC is the beginning record number of the overlay image 
on the kernel program file. 

OVTSIZ is the size in bytes of the image, not Including 
the relocation bit map. 

OVTLOD is the natural load address (as assigned by the Link 
Editor) of the overlay. 

System generation creates the OVT; IPL initializes it. 

SOV - System Overlay Load Table 

SOV is a template which describes the OVT built by system 
generation. It contains definitions for the names of all 
the system overlays in the system. Routines referencing 
overlays do so by name and copy in this module. The value 
of a name is an index into the OVT. 


12.3.2 System Support Routines for Overlays. 

The module DSC . SOVLY. SOVCPR in the system root provides three 
entry points for accessing overlay code. Two of these are for 
entering overlay code and one is for returning from overlay code. 

An overlay may be called from task code using SOVLTO (link to 
overlay). SOVLTO preserves linkage information on the task 
stack. The called overlay may Itself call an overlay via SOVBTO 
(branch to overlay). The second overlay executes, returning to 
the task code via the linkage preserved on the stack by SOVLTO. 

SOVLTO - Link to Overlay 

SOVLTO is used to enter an overlay from system task code. 
The caller places the overlay index from SOV in R9 and the 
address of an overlay area in R8. The overlay is loaded, 
relocated if necessary, and the code is entered in such a 
way that if R1 1 is used for a return address, return will go 
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through SOVRFO. Hence, routines can be called that do or do not 
use push/pop for their entry/exit convention. Any routine that 
has a pointer In the entry vector can be called by this routine. 

SOVBTO ~ Branch to Overlay 

SOVBTO Is used to enter an overlay from another overlay when 
a return path to the first overlay Is not needed. It Is 
used when continuity of logic Is needed but the code will 
not fit within one overlay. The same R8 and R9 Inputs are 
used as for SOVLTO. 

SOVRFO - Return from Overlay 

SOVRFO Is used to return to the caller of SOVLTO. No Input 
registers are needed. All registers of the returning 
routine. Including RO , are preserved, and any error exit 
Indicated by the contents of RO Is taken. 


12.3.3 Size of Overlay Areas. 

The system overlay loader does not support returning control 
(i.e., after calling root-resident code) to an overlay which is 
loaded at a different address from where it was loaded when It 
executed the call to the r oo t -res 1 den t code. The system overlay 
loader does not support a pool of overlays. 

The overlay area must be large enough for the overlay and the 
relocation bit map. Overlay areas can be located anywhere 
convenient for the subsystem. Most are allocated In the task 
segment for the subsystem. 


12.3.4 Coding Overlays. 

System overlays are coded like normal user overlays. Code Is 
free to reference (REF) symbols defined in the overlay and In the 
root and to define data words referencing locations In the 
overlay code itself. This characteristic Is achieved by 
relocating overlays at load time. 

Each overlay must have a table at the physical beginning of the 
overlay that defines the locations of the routines In the 
overlay. When using R9 to specify which overlay to enter, the 
first five bits of R9 Indicate which of 31 possible routines is 
to be used. In the following example, the following link control 
and modules illustrate the construction of code that is to be 
overlay resident. A line with three dots indicates missing code. 
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PHASE 3 

,DMOV37 




INCLUDE 

IN.DISKMGR.OBJECT.DMOTBL 



INCLUDE 

IN. D I SKMGR. OBJECT. DMRTNl 



INCLUDE 

IN.DISKMGR.0BJECT.DMRTN2 



INCLUDE 

IN.DISKMGR.0BJECT.DMRTN3 



PHASE . 

• • 





where the 

routines Include 

5 




IDT 

' DMOTBL' 





REF 

DMRTNl 





REF 

DMRTN2 





DATA 

DMRTNl 





DATA 

END 

DMRTN2 





IDT 

' DMRTNl ' 

DIRECTLY CALLABLE FROM 



DEF 

DMRTNl 

WITHIN OVERLAY AND 

CALLABLE 

DMRTNl 

MOV 

R1 1 ,*R10+ 

THROUGH SOVLTO 




BL 

QNFPSHX 





• • • 

B 

@NFP0PX 





END 






IDT 

' DMRTN2 ' 

CALLABLE ONLY BY SOVLTO 



REF 

DMRTNl 

CALLABLE FROM HERE 

BY BL 



REF 

DMRTN3 

CALLABLE FROM HERE 

BY BL 



DEF 

DMRTN2 




DMRTN2 

• • • 






BL 

@DMRTN3 





DATA 

X 




X 

• • • 

BL 

@DMRTN1 





DATA 

Y 





• • • 

B 

(aSOVRFO 





END 






IDT 

' DMRTN3 ' 




DMRTN3 

MOV 

R1 1 ,*R10 + 

CALLABLE ONLY FROM 

WITHIN 



BL 

@NFPSHX 

OVERLAY VIA BL 




• • • 

B 

(aNFPOPX 





END 





The overlay loader is 

capable of handling the 

call 

and return 

sequence of either the 

standard push. pop or 

the 

ent e r /exi t 

routines , 

as Illustrated in the preceding examples. 
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12.3.5 Calling Routines In an Overlay. 

Overlay-resident code Is called with the calling sequence 
illustrated below. Entry from the root code Into each of the 
routines In the preceding example Is shown. All registers except 
RO are transmitted to the called routine unchanged. RO Is 
cleared . 


COPY 

DSC. TEMPLATE. ATABLE.SOV 

• • • 

LI 

R9,DMOV37 TO 

ENTER DMRTNl 

LI 

R8,<overlay area 

address > 

BL 

@S0VLT0 


DATA 

<error return> 


• • • 

LI 

R9,DMOV37+>800 

TO ENTER DMRTN2 

LI 

R8,<overlay area 

address> 

BL 

esOVLTO 


DATA 

<error return> 



• • • 


12.3.6 Internal Design Considerations. 

The entry SOVLTO pushes the return address onto the current run- 
time stack. Calling one overlay from another Is not supported In 
that the stack does not have Information on which overlay to load 
and therefore the first overlay Is not loaded on the return path. 

When an overlay Is loaded into memory, a check Is made to see If 
relocation Is needed. If so, the relocation bit map Is also read 
In. If the load address of the overlay and the address of the 
overlay area In which to load It are equal, no relocation Is 
performed. Otherwise, relocation may be needed. Each location 
Indicated In the bit map Is examined. If the reference Is less 
than the natural load address of the overlay (computed by the 
Link Editor), relocation Is not necessary for that location. If 
the reference Is greater than or equal to the natural load 
address, the reference is altered by the following formula; 

NRV = ORV - (NLA - ALA) 

where : 

NRV Is new reference value 
ORV is old reference value 
NLA Is natural load address 
ALA is actual load address 
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Hence, the overlay area must be large enough to contain both the 
bit map and the overlay, when the overlay area Is part of a pool. 


12.4 WRITING AND LINKING A PASCAL SYSTEM TASK 

System tasks written In Pascal may be written In several ways, 
depending on what portions of the task are In Pascal. If the 
entire task Is written In Pascal and enough space Is available to 
accommodate the Pascal run-time support, the task can make use of 
Pascal routines for stack and heap management, as well as other 
run-time support. 

If task space Is not abundant, Pascal run-time routines for stack 
and heap management can be replaced by other routines to 
economize on space. These routines define entry points that are 
replacements for labels known to the Pascal base routine, 
R$TASKDP. The routines are described In the paragraphs that 
follow. 

UTR$ST 

This module In DSC . UTCOMN . SOURCE . UTR$ ST contains routines 
that perform stack and heap Initialization and that perform 
termination processing. The routines are named R$GSHS, 
R$GSHP, and S$STOP. The module references labels RSTACK, 
STKSIZ, HEPSIZ, MDNAME, and CLNUP that are defined In a data 
module supplied by the user. 

Parameters Module 

If using UTR$ST for stack and heap management, the user must 
build a module that defines the parameters RSTACK, STKSIZ, 
HEPSIZ, MDNAME and CLNUP. The CLNUP parameter Is optional; 
It specifies the address of an end action routine. A label 
MDNAME can be defined to contain the ASCII string which 
should be shown In a message to the system log when the task 
aborts. For example, the following portion of code In 
DSC. LOG. SOURCE. LGADAT sets the parameters for the DNOS 
accounting log processor. In this example DATAM Is a macro 
that generates the number of occurrences, specified In 
argument two, of the value In argument one. 
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IDT 'LGADAT' 

DSEG 

DEF RSTACK, STKSIZ,HEPSIZ ,MDNAME 
TEXT 'LGACCT' 

DATAM >3333,200 USE 200 WORDS OF STACK 

EQU $-RSTACK 

DATAM >3636,300 AND 300 WORDS OF HEAP 

EQU $-RHEAP 

DATAM >4242,32 MARGIN BUFFER 

END 


When the Pascal task Is linked, the modules which replace the 
Pascal run-time modules must be explicitly Included so that they 
override the default modules collected from the run-time library. 
The following example link control file for building a task 
Includes Its own parameters module (LGDATA) from 
VOLOBJ.LOG. OBJECT and the UTR$ST module from 

VOLOB J . UTCOMN • OB JE CT . It Is the link stream for the log 
formatter task from DSC . LINK. SYSTEM, LGFORM. 

NOPAGE 

NOSYMT 

LIBRARY VOLOBJ.LOG. OBJECT 

LIBRARY P AS CAL. MI NO BJ , PASCAL . LUNOBJ , PASCAL . OB J 

LIBRARY VOLOBJ. UTCOMN. OBJECT 

LIBRARY VOLOBJ. PASASM. OBJECT 

PROCEDURE DUMROOT 

DUMMY 

INCLUDE VOLOBJ. S$SGU$ .DUMROOT 

PHASE 0 , LGFORM, PROG >C000 ; SYSTEM LOG FORMATTER TASK 

INCLUDE (R$TASKDP) 

INCLUDE (LGFORM) 

INCLUDE (LGDATA) 

INCLUDE (UTR$ST) 

INCLUDE (UTPTCH) 


An alternate to building the parameters module such as LGDATA is 
to make use of the Pascal exception handler. In this case, the 
text for MDNAME must be defined In an assembly language module so 
that messages to the system log have a module name text. The 
routine ONEXCEPTION must be declared In the Pascal task as: 

PROCEDURE 0NEXCEPTI0N(HANDLER_L0CATI0N; INTEGER); EXTERNAL; 

When the task aborts, this procedure Is called, passing to It the 
location of the Pascal procedure which Is to perform the cleanup 
processing. The exception handler has access to any variables in 
common or In the main program's stack frame, but other stack 
frames cannot be assumed to still be accessible. Optionally, the 


MDNAME 
RSTACK 
STKS IZ 
RHEAP 
HEPSIZ 
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exception handler may be declared to accept a single Integer 
parameter, which will then be set to the Internal message number 
of the error condition. 

The following example shows how a procedure CLEANUP might be used 
to handle exceptions. In this case, it merely writes a message 
ERROR IN PROCESSING to file F. 

PROGRAM EXAMPLE; 

VAR F: TEXT; 

PROCEDURE ONEXCEPTION(HANDLER_LOCATION: INTEGER); EXTERNAL; 
PROCEDURE CLEANUP; 

BEGIN 

WRITELN(F, 'ERROR IN PROCESSING'); 

END ; 

BEGIN 

REWRITE( F); 

ONEXCEPTIONC LOCATION ( CLEANUP ) ): 

main body of program 

END ; 


12.5 DETAILS OF DNOS SYSTEM TASKS 

The kernel program file (named according to the system name 
specified during system generation) and the utilities program 
file .S$UTIL Include a number of system tasks that support 
execution of DNOS. Those which carry a section indication in 
Table 12-1 are described in detail in that section of this 
document; those with no section number are described only in this 
table . 
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Task Name 

DEBUG 

DIOU 

DISKMGR 

FILEMGR 

INV 

lOBREAK 

lOTBID 

lOU 

IPG 

lUV 

JOBMGR 

LGACHN 

LGACCT 

LGFORM 

LGGLOG 

LGRCRT 

LOGON 

NAMMGR 

PMOVYL 

PMPASP 

PMPDEL 


PMPINS 


PMPMAP 

PMRWTK 

PMSBID 

PMSBUF 

PMTBID 

PMTERM 

PMTLDR 

PMWRIT 

RPRCP 

RESTART 

RESTART2 

SAVRES 


System Tasks 


Table 12-1 DNOS System Tasks 
Section Purpose 

16 Aids In debugging system code 

10 Performs device I/O utility functions 
Performs the Disk Management SVCs 

11 Performs file management operations 
Performs the Initialize New Volume SVC 

12 Performs the break key function 
10 Bids a task from DSR 

10 Performs I/O utility operations 
10 Swaps IPG data for tasks that do not 
simultaneously fit In memory 
Performs the Install Disk Volume and 
Unload Disk Volume SVCs 

8 Performs job management 

14 Puts spooler data In the accounting log 
14 Formats accounting log messages) 

14 Formats system log messages 
14 Recovers system log data after crashes 
14 Creates log files 
12 Processes user log-on procedure 
10 Performs name management SVC 
Performs the Load Overlay SVC 
Performs the Assign Program File Space 
SVC 

Performs the SVC processing for Delete 
Task, Delete Procedure or Program 
Segment, and Delete Overlay 
Performs the SVC processing for Install 
Task, Install Procedure or Program 
Segment, and Install Overlay 
Performs the Map Program File SVC 
Performs the Read/Write Task SVC 
Information transfer 
Processes the Scheduled Bid Task SVC 
Processes the Modify BTA/JCA Size SVC 

9 Processes Bid Task SVC 

9 Cleans up a task that has terminated 
abnormally 

9 Loads tasks Into memory 
7 Writes modified segments to disk 
12 Processes Return Code Processor SVC 
12 Establishes Initial system conditions 
12 Establishes Initial system conditions 
10 Saves and restores name manager segments 
to and from disk 
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The remaining system tasks in S$UTIL support SCI and utility 
functions and some of these are described in detail in the DNOS 
SCI and Utilities Design Document * Table 12-2 lists the system 
tasks that support SCI or utilities. 


Table 12-2 System Tasks t.o Support SCI and Utilities 
Task Name Function 


CRV 

LTS 

MLP 

OPERATOR 

RAL 

SCS 

SCU 

SIS 

SJSSTS 

SMM 

SMS 

XJM 

XPD 


Checks and resets disk volumes 
Lists terminal status 
Modifies LUNO protection 

Channel owner for the operator interface 
Releases all LUNOs for a job 
Shows channel status 

Performs system configuration commands 

Shows I/O status 

Shows job and task status 

Shows system memory map 

Shows memory status 

Monitors execution of jobs 

Displays performance data 


Many other tasks found in the S$UTIL program file are not system 
tasks, but they do support SCI and utilities. They are described 
SCI and Utilities Design Document . 

The paragraphs that follow describe some of the system tasks that 
are part ojE DNOS but are not described elsewhere in this 
document . 


12.5.1 Log-On Task (LOGON). 

The log-on task is bid by lOTBID whenever a command definition 
table (CDT) gives the LOGON ID as the primary task to be bid. 
The supplied log-on task can be replaced by a user-written task 
if the user wishes to have a different system environment than 
that provided. That task must be a system task if it is to 
examine system structures for currently executing jobs. 

One of the special responsibilities of LOGON is to initialize the 
system time and date. The first time LOGON is bid, the year 
field (kept in the CSEG NFCLKD as YEAR) is zero. LOGON prompts 
for time and date and initializes the system to the data 
supplied. In subsequent bids of LOGON, the year field is 
checked; if it is nonzero, no time and date are queried. 

The supplied log-on task solicits a user ID, passcode, account 
ID, and job name from the terminal performing the bid if the 
.S$SCA file indicate that log-on is required at that terminal. 
This data is kept for each terminal, and it is modifiable by a 
Modify Terminal Status (MTS) command to SCI. Before the job is 
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started, the break key sequence Is enabled at the terminal being 
used . 

If a job already exists for the user ID, passcode, and job name 
given, and reconnect is specified for the terminal, the user Is 
asked If he wishes to reconnect (that Is, run In the same job). 
If the user answers affirmatively, LOGON bids the desired task 
under the already existing job. 

If the user does not want to reconnect to an already existing 
job, or If the job named does not already exist, LOGON Issues a 
Create Job SVC to start a job at the terminal being used. Among 
the parameters supplied In the SVC are the segment Identifier of 
the name manager segment, the Initial task to be bid, program 
file LUNO required, and any bid parameters passed from the CDT. 

If the user makes an error In supplying log-on data, the Create 
Job SVC falls. In the case of failure, LOGON prompts again for 
the log-on data. A maximum of three attempts Is allowed before 
LOGON terminates. Exceeding the limit Is logged to the system 
log so that violations of system security may be monitored. 

For some log-ons, the data gathered from the user Is different. 
If the CDE for the key used to log-on Indicates that even loading 
Is to occur, log-on establishes the new terminal within an 
existing job. If the CDE Indicates that a default user ID should 
be used, LOGON will not prompt for user ID and passcode. Using 
the appropriate ID and job name, the terminal Is then set up 
within one of the jobs specified by the CDE. 

The S$SCA file contains Information referenced by the LOGON task 
to determine mode and the proper LOGON prompts for terminals In a 
system. An S$SCA entry Is created by the Modify Terminal Status 
(MTS) processor. The first field In the record Is the device 
number associated with a specific terminal. The next four fields 
contain the default values for the user ID, account number, 
passcode and/or job name If they are not prompted for at logon. 
Finally, an entry contains eight flags (Y for YES and N for NO) 
that specify the following options: 

* Login required 

* VDT mode 

* Do not solicit job name 

* Reconnect disabled 

* Solicit account number 

* Solicit name 

* Manager files 
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* Terminal off 

* VDT mode default 

If an entry has not been created for a station through the use of 
MTS, the following defaults are used: 


LOGIN REQUIRED - NO 
VDT MODE - NO 
DON'T SOLICIT JOB NAME - NO 
RECONNECT DISABLED - NO 
SOLICIT ACCOUNT NUMBER - NO 
SOLICIT NAME MANAGER FILES - NO 
TERMINAL OFF - NO 
VDT MODE DEFAULT - NO 


The S$SCA file is also used by the List Terminal Status (LTS) 
processor. If an entry does not exist, LTS outputs the defaults. 


12.5.2 System Initialization Tasks (RESTART and RESTART2). 

The initialization task is the first task to run after IPL. It 
checks for the existence of the system log files. If they do not 
exist, RESTART attempts to create them. If the files cannot be 
created, RESTART outputs a message to the system log device. 
RESTART then attempts to create the accounting log files. If the 
accounting log files cannot be initialized, a message is output 
to the system log. 

RESTART then initializes the capabilities list file, S$CLF and 
restores the global logical name segment. It deletes temporary 
files and bids all global channel owner tasks which support DNOS 
and the utilities. RESTART then bids a user-defined 
initialization task if one was specified during system 
generat ion . 


12.5.3 RPRCP. 

This task processes the Return Code Processor SVC (SVC >4C). It 

retrieves variable text Information from the call block supplied 
as an argument in the call. If the supplied call block has an 
error for which the message requires variable text and the 
calling task has supplied a variable text buffer, then RPRCP 
extracts the appropriate variable text from the call block and 
places it into the buffer. To do the extraction, RPRCP follows a 
set of tables found in the module DSC . REQPROC . SOURCE , RPRCDA. 

RPRCDA includes an entry for each SVC message in 
DSC . ME SS AGE S . T EXT . S VC that has variable text as part of the 
message. In addition, the table has entries for the following: 
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* Each SVC which can return an I/O error has an entry for 
each return code which is no t to be replaced by the 
corresponding I/O message. For example, disk manager 
error >202A must appear in the table since the disk 
manager SVC can report I/O SVC errors, but 2A is a 
special disk manager error which is not to be replaced 
by the corresponding I/O error. This error has no 
variable text and appears in the table with such an 
indication. The exceptions to this rule are F3 and F4, 
which do not need to be duplicated for each SVC. 

* The last code in the table must be a dummy entry to 
allow error codes >F0 and >F3 to generate the same 
output for all SVCs. 

If an error is encountered while processing the variable text, 
searching for an LDT, or accessing a task segment the error 
condition is returned as an error of the >4C SVC. This allows 
the calling task to terminate and pass back the error condition 
without doing error checking on the error processing SVC. If the 
SVC block passed to RPRCP has no error byte, a similar 4Cxx error 
is returned. 

A number of special cases are considered by RPRCP. The Poll Task 
Status SVC (SVC >35) returns status (error) byte 00 when the 
status message needs to specify the state in byte 3. When RPRCP 
detects the Poll Task Status, it retrieves the state information, 
passes it back as variable text, and exits the RPRCP code. 

Another special case is that of Activate Suspended Task (SVC >07) 
and Activate Time Delayed Task (SVC >0E) . Each of these can 
return a status byte of 00 as a meaningful status message. These 
cases are passed along for scanning in the RPRCDA table. All 
other SVCs with status bytes of 00 cause RPRCP to report a 4Cxx 
error saying that the passed error byte is not an error. 

The cases of FO and F3 error bytes all use the same table entry, 
passing back the SVC code byte as variable text for the message 
that Indicates that an unsupported SVC was issued (for the FO 
error) or that a privileged SVC was Issued (for the F3 error). 

A number of SVCs have no room for an error byte. The table named 
EXCTBL is searched to see if the supplied SVC block uses one of 
these exceptions. If so, the 4Cxx error indicating no error byte 
is returned to the caller. 

For all other cases, the table in RPRCDA is scanned for the 
specified SVC and status byte. If an entry is found, the 
appropriate variable text is Inserted into the buffer. If no 
entry is found, the SVC is examined to see if it might return I/O 
errors. This test is made by scanning the table lOTBL in RPRPC. 
If the SVC code in the supplied block is in this table, variable 
text is built using the SVC code and status byte for the message 
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number which Indicates an I/O error in processing another SVC. 

The table in RPRCDA carries a two-word entry for each SVC code, 
status byte combination that RPRCP must find. The first word is 
the SVC code, status byte pair and the second word is the address 
of decoding Information. The decoding information is composed of 
the following types of entries: 

1. NOVAR - No variable text is needed; this is used for 
those cases that must appear in the table to mask 
replacement by I/O error codes 

2. Cxy - Convert the byte of Information at offset xy in 
the call block into hexadecimal ASCII for variable text 

3. Dxy - Convert the byte of information at offset xy in 
the call block into decimal ASCII for variable text 

4. Eabxy - Echo the ab words of data at offset xy in the 

call block exactly as they are for variable text (xy 

must be an even offset into a call block on an even 
bounda ry ) 

5. P - Use the address as offset 22 into the call block as 
a pathname pointer and move the pathname for variable 
text 

6. L - Use the LUNO at offset 3 into the call block to 

search the LDT list and return the resource name for 

variable text 

Rules about combining these codes into legal combinations are 
found in the RPRCDA module. 


12.5.4 lOBREAK. 

The lOBREAK task performs the hard break function. It uses the 
following order to cause tasks to terminate: foreground down to 

1 task, then background tasks, then the last foreground task, 
with highest priority first. 

In addition, the following rules hold: 


* 

* 

* 

* 


Skip file manager 
Skip self 

If this task already being terminated 
stop 

Skip task at different terminal 


by hard 


break , 
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Skip non-leaf mode task (that Is, kill at lowest level 
first) 
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SECTION 13 

SYSTEM GENERATION UTILITY 


13.1 OVERVIEW 

System generation (sysgen) Is the process of creating an 
operating system. This process Involves specifying all necessary 
features, describing the devices that will be available to the 
new operating system, and constructing an operating system with 
the stated features and devices. The difficulty of this process 
Is compounded by the flexibility required in the sysgen software 
to configure only the desired features Into the operating system. 

The DNOS user is given a utility called SYSJEN, which asks 
questions that may be answered In English. These questions 
determine which features will be included In the new operating 
system and which devices will be used. The SYSJEN utility 
collects this data and produces a file called a configuration 
file. This file contains all of the Information needed to 
construct an operating system with the desired features. SYSJEN 
also produces a file that describes the data structures needed to 
produce an operating system with the desired features In the 
internal format of the new operating system. This file is called 
the source file. The parts needed to complete the construction 
of the operating system with the desired features are then chosen 
by the SYSJEN utility. This information is placed in the link 
control files. These files describe which modules are needed in 
the operating system and the order in which they are to be used. 
If communications devices are to be included, these files also 
describe which modules are to be included in the communications 
device service routines and the communications software 
scheduler. Combining these modules in the desired way is 
controlled by a batch stream. After the batch stream combines 
the different parts of the new operating system, the system is 
available for use. 


13.2 SYSJEN STRUCTURE 

SYSJEN is a Pascal task, consisting of a root phase and three 
overlays. The flow of execution is from the first overlay to the 
second, and from the second to the third. The root contains the 
main driver for the program, a collection of support routines 
needed in more than one overlay, and all of the I/O routines. 
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The main driver consists of a loop that calls other routines. 
This main loop is called the INQUIRE loop. SYSJEN begins by 
loading the initialization (INIT) overlay and calling procedure 
INIT. The second overlay, INTERACT, is then loaded, and the main 
loop is entered. Another loop calls ASKQST to ask system 
questions. When all system questions have been asked, DEFSTR is 
called to define system structures, devices, jobs, channels, 
XOPs, and SVCs. DEFSTR is called from the main loop so that 
whenever a user changes a system question, he is asked that 
question Immediately, even if he was in DEFSTR at the time of the 
change. The stop routine, STOPRT, is also in the main loop; this 
permits the user to change answers after entering the stop 
routine (for example, when a warning message is Issued from 
STOPRT). If a user answers yes to the build question, STOPRT 
loads the third overlay, BUILD, and calls the major routine in 
that overlay, BILDRT. The error-handling routines are in the 
root phase; since the program is written in Pascal, the run-time 
support routines are also in the root. 

The INIT overlay Initializes all of the data structures used by 
SYSJEN, opens the JENDAT file, and opens the Interactive device. 
This overlay also verifies that the JENDAT file is the correct 
one for the program. The device characteristics of the 
interactive device are read to make the listing routines work for 
that device. Many data structures are Initialized in the INIT 
phase. The data needed to define devices is kept as sets of 
device types, device names, and PDT names. The locations of 
questions in the JENDAT file ^re stored in array QTX , and the 
type of each question is placed in array TQ . The "preanswered" 
questions are answered and marked as nonllstable. Next, the 
implication tables are filled. Pascal heap space needed for 
names and pathnames is allocated. The XOP and SVC tables are 
emptied, and all list headers are made NIL. The flow of control 
is linear. 

The INTERACT overlay contains all routines that ask questions 
about system data and system structures. The command mode 
routines are also in this overlay, since they are interactive. 
The major routines ask the system parameter, device, XOP, and SVC 
questions. The command mode routines permit the user to change, 
add, and list the previously entered data. This overlay also 
contains the module that reads old configurations, since they 
appear to be Interactive responses. 

The INTERACT overlay has a complicated flow structure, since the 
command mode is called from the TRAN routine, which parses user 
answers; also, command mode calls the major routines in the 
INTERACT overlay. These routines in turn call the parser. The 
user can quickly exhaust all stack space because of this indirect 
recursion if the CMD key Is struck repeatedly. 

The BUILD overlay produces the files necessary to complete 
sysgen. One file produced is D$SOURCE, which contains the 
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initial STA; the Interrupt vectors ; the special table area SSBs; 
the system JSB, PDTs , RPSDAT, and system JCA. SYSLINK, lOULINK, 
and DMLINK are the files that link the operating system. Other 
link control files for communications device service routines and 
the communication software scheduler are generated If there Is 
any communication device. ALGSSTRM is the batch stream used to 
build the system. These files are built by calling a COPY module 
whose parameter Is the record number at which to start the copy. 
This routine copies data from JENDAT to the appropriate file and 
makes any modifications necessary for tailoring the data to the 
current configuration. The processing Is linear In this overlay. 


13.3 DETAILS OF THE SYSJEN ROOT PHASE 

The major root routines are SYSJEN and STOPRT. SYSJEN begins 
execution. After SYSJEN has called INIT to Initialize all 
constants and pointers, the INITl procedure Is called to read an 
old configuration, If needed. The value of the synonym INCON 
specifies which configuration and indicates that nothing need be 
read if the value returned Is INCON. The program then enters a 
loop. The answer tables ( QANS , QANSBUS) are scanned to find any 
unanswered questions. The first one found is then asked by 
calling ASKQST, with the number of the question stored in common 
variable QTA. If the user hits the CMD key at any time, s/he 
enters the command mode. (In command mode, a previous answer may 
be changed.) The loop begins each scan at the start of the 
question list so that questions with changed answers will be 
asked next. If no questions are found unanswered, DEFSTR is 
called to define devices, XOPs, and SVCs. When the routine 
returns from DEFSTR, STOPRT Is called to ask whether to save the 
configuration only, or to build the system. 


13.3.1 STOPRT. 

STOPRT determines if a build is possible. If it is possible, 
STOPRT then asks if a build Is desired. If a system does not 
have a disk defined, a warning message Is given. The user can 
hit CMD and then INQUIRE to return to DEFSTR (to add a device). 
If a build is not possible (caused by typing STOP), the user is 
asked If a save is desired. If a build is chosen, the BUILD 
overlay Is loaded and procedure BILDRT is called. If the save 
option is chosen, the save routine (SAVECN) from the second 
overlay is called and the configuration listing is produced. 


13.3.2 Support Routines. 

Two types of support routines are Included: I/O routines and 

string manipulation routines. The majority are I/O routines. 
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The I/O routines perform the calls needed to read data from the 
JENDAT file, to read the Input configuration, to backspace the 
Input configuration, to write the output flies, and to read and 
write to the user station. The JENDAT records are always read 
Into the same buffer, JMSG. The sequential file routines always 
use buffer TXT, whether reading or writing. The Interactive 
writes use buffer BUF. The Interactive reads use buffer RPBUF. 
The sequential call blocks are allocated from the heap on opens 
and released on closes. The JENDAT and Interactive call blocks 
are In common variables G and CALLBLK, respectively. 

The I/O routines, their uses and parameters are as follows: 

* GJ(X) “ Read JENDAT record number X 

* LONGPR(X) - Read JENDAT record numbers starting at X, 
and display to user until logical link Is 0 

* PRINT - Direct output to the user or batch listing file 
. S$SGU$ .<NAME> .ERRFIL 

* RSET(LUNO) - Open a sequential file for reading 

* REWRIT(LUNO) - Open a sequential file for writing 

* CLOS(LUNO) - Close a sequential file 

* MEOF(LUNO) - Detect end-of-flle 

* BKSPAC(LUNO) - Backspace the LUNO 

* RWSEQ(LUNO) -- Read/write buffer TXT 

* ENCOD ( STR , LOG , X , P , B ) - Write X Into field STR, starting 
at LOG In base B, with P digits of precision. 

* DECODE( STR, LOG ,STAT , VALUE) - Read number VALUE from 
field STR, starting at the location LOG, putting the 
status of the operation In STAT. 

The string manipulation utilities add strings to the output 
buffer TXT. They all use the common variable BG to point to the 
location at which the Insertion begins In the text. The routines 
and their uses and parameters are as follows: 

* ADDNMB(X) - Insert decimal number X (left justified) 

* ADDHEX(X) - Insert X as a four-digit hexadecimal number 
(Includes > ) 

* ADDNAM ( X , LEN ) - Insert the name X of length LEN 

* ADDPAT(X) - Insert a pathname to which X points 
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13.4 DETAILS OF THE INITIALIZATION PHASE 

There are six routines In the INIT overlay: INIT, INITCN, 

INITDB, INITHD, INITAL, and INITOP. 

* INIT - Opens the JENDAT file and verifies compatibility 
between the file and the program. It also opens the 
Interactive device and checks the values of synonyms 
assigned by the SCI command procedure used to start 
sy s gen . 

* INITCN - Loads the arrays of constants used by SYSJEN 

* INITDB - Initializes list headers, Implication tables, 
the XOP tables, all answers to system questions, 
questions unanswered by the user, questions that are 
nonlistable, and questions that are preanswered to be 
false 

* INITOP - Initializes the SVC tables 

* INITAL - Assigns LUNOs to Input and output files 

* INITHD “ Initializes preanswered questions 


13.4.1 INIT. 

INIT first finds the value of $$M0. This Indicates whether the 
program Is running In batch mode. Then, the value of $CSNAM Is 
found to Indicate the name of the system being built. The 
station Is opened next. A Read Device Characteristics SVC Is 
Issued to find the number of lines used by the device. The 
listing routine uses this number to get a maximum amount of data 
to the screen before waiting for the user to signal 
acknowledgment. Finally, JENDAT Is opened, and the first record 
(record 0) Is read to find the version number of the file. If an 
Incompatibility is found, an error message Is sent to the user 
and processing stops. If no problem Is found, INITCN is called, 
followed by a call to INITDB. 


13.4.2 INITAL. 

INITAL creates the S$SGU$ directory on the target disk, if one 
does not exist. It then creates the configuration directory In 
the S$SGU$ directory. If one does not exist. It then creates all 
output files needed by sysgen and assigns LUNOs for use by the 
program. 
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13.4.3 INITCN. 

INITCN begins by printing an Informative message to the user 
Indicating that execution has begun. Next, the array indicating 
the presence of TILINE devices (TILPRE) Is set to zero. All 
positions on the seven expansion chassis are marked unused. Six 
sets of devices are filled with devices containing the desired 
characteristics. These are LEGALDEVICES , TILINETYPES, 
XCESSREQUIRED, TIMEOUTDEVI CES , CHARQTYPES and ASYNCTYPES. The 
array of device names (DEVNAM) is filled. Array QTX is 
Initialized with constants from file JDICONS. QTX holds the 
pointers to question text In the JENDAT file. TQ , the array of 
system question types, Is the last array to be filled In this 
routine • 


13.4.4 INITDB. 

INITDB initializes all answers to system questions (QANS), 
questions unanswered by the user (QANSBUS), all questions that 
are nonllstable (QLIST), and all questions that are preanswered 
(QHASDEF) to be false. Next, all implications are cleared (that 
Is, YESINF and NOINF are made false). Now the Implications are 
made. All names and pathnames for system questions are allocated 
from the heap. The list headers are made null, and the array of 
PDT names (PDTNAM) is Initialized with text. 


13.4.5 INITHD. 

INITHD establishes preanswered questions. QANS Is made true or 
false (as needed), QANSBUS Is made true, QHASDEF Is made true, 
and NUMBIN Is filled where needed. (NUMBIN holds either a number 
or a pointer to a name or pathname.) 


13.4.6 INITOP. 

INITOP begins by Initializing all SVC Information to false. The 
array, (DESVC), Is two dimensional; of size NOSVCGROUPS by 
SVCPARMS. NOSVCGROUPS Is a small Integer constant, currently 14. 
SVCPARMS Is a scalar, with components DESIRED, and REQOND. These 
components represent whether the user wants to Include the SVC 
and whether It Is required. The array of SVC IDs (OPSVC) is 
Initialized to false. This array is used to build RPSDAT and to 
decide which optional processors to include In the link stream 
built In the BUILD phase. INITOP then Initializes DESVC by 
assigning those values that are Initially true. Next the SVCGRP 
array Is filled. This array Is used In the BUILD phase to decide 
which SVCs have been chosen. A value of 0 indicates that the SVC 
is required, -2 Indicates nonexistence, -3 Indicates that the SVC 
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is Included If the common option is chosen, and other numbers 
indicate an SVC group chosen by group name. 


13.5 DETAILS OF THE INTERACTIVE PHASE 

Major routines in the INTERACTIVE phase are ASKQST, DEFSTR, 
COMMND, CHANRT, DELRT, and LISTRT. The translation routine, 
TRAN, is also in this overlay and is called by any routine 
needing a response parsed. Several other support routines are 
available throughout the phase. 


13.5.1 General Support Routines. 


TRAN 

TRAN parses the user response and returns a token in common 
variable TR. If the user terminates a call with the CMD 
key, TRAN directly calls COMMND. This routine removes 
blanks from the answer. It also Intercepts a STOP any time 
one is entered by a user. 

COMMND 

COMMND calls TRAN on each user command entered. Then the 
proper routine is called to perform the desired function. 
The routines called from COMMND are CHANRT, DELRT, and 
LISTRT. The INQUIRE command causes an escape from the 
COMMND routine. 


SETUP 

SETUP is used by INITl to convert answers read from a 
configuration file to what looks like interactively 
collected data . 

Error Routines 

Two error routines in the INTERACTIVE phase are ERRMSG and 
PUNT. ERRMSG produces the set of questions and error 
messages that result from answering a question Incorrectly 
that was asked by ASKNAM, ASKNMB, ASKYN, OR ASKPAT. If the 
error occurs while a configuration is being read, PUNT is 
called to indicate which record was in error. PUNT 
terminates the program. 


13.5.2 Asking System Questions. 

The x\SKQST routine asks all system questions by looking for the 
question type of QTA in array TQ . Then, one of the five 
prompting routines (ASKNAM, ASKNMB, ASKYN, ASKPAT, ASKELM) is 
called to prompt for and validate the answer. This is one of two 
major drivers in the INQUIRE mode. These five routines all use 
the numeric fields of the JENDAT file for information about 
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acceptable answers to the question. The fields that contain 
answer information are DEF , AAT , LB, UB and NEXT. DEF contains a 
default answer. AAT is the acceptable answer type. LB and UB 
are lower and upper bounds on the answers. NEXT is the record 
number which logically follows this question. 

ASKNAM 

ASKNAM is used to ask name questions. This routine uses the 
DEF field to represent the ordinal of the default answer, if 
any exists. The possible values for AAT are as follows: 0 
indicates that any answer is acceptable; 1 indicates that 
the only acceptable answer is either LB or UB (that is, an 
answer must begin with a letter whose ordinal is LB or UB) ; 
and 2 indicates that the question must be answered. If DEF 
is 0, no default answer exists. 

ASKNMB 

ASKNMB uses DEF as the default numeric answer. The possible 
values for AAT are as follows: 0 indicates that any answer 
is acceptable; 1 means that an answer must be larger than LB 
to be acceptable; 2 indicates that the answer must be 
between LB and UB inclusively; and 3 indicates that the only 
acceptable answers are LB or UB. This routine is a 
function. 


ASKYN 

ASKYN uses DEF in a type transfer to Boolean values as the 

default answer, such that 0 represents false and 1 

represents true. The possible values for AAT are as 

follows: 0 indicates that a default exists and 1 indicates 

that no default exists. This routine is a function. 

ASKPAT 

ASKPAT uses the logic of ASKNAM for producing prompts and 
error messages. Then, this routine checks for valid 
pathname syntax, producing any prompting necessary because 
of pathname syntax. 

ASKELM 

ASKELM uses the logic of FNDANS. It will not stop unless 
the answer is found or the command key is entered. 

FNDANS 

FNDANS starts with record number NEXT, comparing the TXT 
field of each record with the answer supplied by the user. 
When a match is found, the DEF field is returned as the 
answer. FNDANS is a function, returning false if no match 
is found. 
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13.5.3 Defining Structures. 

DEFSTR, the other driver in the INQUIRE mode, defines devices, 
XOPs, and system-supplied optional supervisor calls. The 
routines used are ADDDEV, ADDXOP, and ADDSVC. They include the 
logic needed to call the prompting routines for user interaction, 
answer validation, and error message production. 

ADDDEV 

ADDDEV asks questions that allow the user to define devices. 
Also included are the routines ADV2, ADV3, ADV4, DEVINT, 
RENAME, ADDTPD, ADDVDT, ADDSD, and ADDCOM, which are 
continuations of ADDDEV. ADDDEV initializes a local copy of 
an empty device definition and calls DEVINT to ask interrupt 
and address-related questions. ADV2, ADV3 and ADV4 are 
called to ask other devi.ce questions. These routines ask 
all of the unanswered questions. Then, RENAME is called to 
revison bar off name this device. If the user answers all 
questions, a permanent copy is created from the heap and 
linked to all other devices on a singly linked list. ADDTPD 
is called to ask more TPD questions. ADDVDT is called to 
ask more VDT questions. ADDCOM is called to ask more 
communications device questions. ADDSD is called from ADV3 
to ask more special device questions. 

The declaration for a device is as follows: 

DEVICE = RECORD 

LINK : 

DVTP : 

INTRPT : 

POSITION : 

CHASSIS : 

SYSNAME : 

TIMEOUT : 

CHARQ : 

XCESS : 

CRUBIT : 

NODR : 

INTERFACE : 

CHNNMB : 

ADDRESS 

CASE DEVTYPE OF 
DS, DK : ( RECSIZ 

); 

LP ; ( WIDTH 

PMODE 
XCHAR 
MULATOR 
LP_SPEED 

); 
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VDT : 


KSR : 


ASR : 
COM ; 


SD : 
VT : 


( VDT_TYPE 

GOT_A_PR INTER 
SPEED 
SWITCHED 
OUTPUT_FIFO 

); 

( TERMINAL_TYPE 
BAUD_RATE 
ACU__PRESENT 
ACU__ADDRESS 
ECHO 

FULL_DUPLEX 
COMM_INTERFACE 
SWITCHED LINE 


INTEGER 

BOOLEAN 

INTEGER 

BOOLEAN 

INTEGER 


INTEGER 

INTEGER 

BOOLEAN 

INTEGER 

BOOLEAN 

BOOLEAN 

INTEGER 

BOOLEAN 


CASXCESS : BOOLEAN " RECORD = TRUE 


) 

( 

); 

( 

BOARDTP 

USRBRDTP 

SPNAME 

BUFSIZ 

NOMDL 

IPCNOSES 

PROTOCLS 

); 

( SDNUMB 
SDTIL 
( VTNUMB 


COMBRDTP; 

COMBRDTP; 

WRD; 

INTEGER; 
INTEGER; 
INTEGER; 
ARRAY [0..3] 

INTEGER; " 
BOOLEAN) ; " 

INTEGER) ; " 


OF PROTO_REC; 

SD NUMBER 
TILINE DEVICE 
// OF VT 


END; 
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XOPVECTOR = RECORD 

HERE : BOOLEAN; " XOP DEFINED 

XOPPC : ASMNAM; ” ENTRY POINT LABEL 

XOPWP : ASMNAM; ■" WORKSPACE LABEL 

XOPNAME : PPTH '• PATHNAME OF OBJECT POINTER 

END; 

XOPA : ARRAY [0..14] OF XOPVECTOR; 


13.5*4 Changing Structures. 

To change a structure, the user must first Identify It. The 
system then searches for the specified structure. If It Is 
found. It Is deleted and redefined. The routine CHADEV handles 
this processing for devices, while CHANRT handles It for XOPs. 
CHANRT calls routines FNDQST, CSYQST, FNDXOP , and ADDXOP. CHADEV 
calls FNDDEV, DELDEV, RENAME, and ADDDEV. 

FNDQST 

FNDQST Is used by CHANRT to decide which question Is being 
abbreviated by the user. The questions are scanned 
sequentially until one that has been correctly abbreviated 
Is found. To correctly abbreviate a keyword, both the 
keyword and the abbreviation must begin with the same 
letter. All letters In. the abbreviation must appear In the 
keyword and in the same order. The first letter following a 
blank in the keyword must match the first otherwise 
unmatched letter In the abbreviation. If the abbreviation 
Is unmatched, the value returned by this function is false. 

CSYQST 

CSYQST changes system questions. If the question Is 
currently preanswered. It Is marked unanswered and made 
llstable. Any other questions between this question and the 
expansion card questions are unanswered. 

FNDDEV 

FNDDEV asks for the device name and searches the device list 
for a device with that name. The pointer to the device Is 
returned. If found, or an error message is produced. 

FNDXOP 

FNDXOP verifies that a given XOP has been defined on the 
level that the user enters. If that level has not been 
defined, an error message Is produced. If the XOP was 
defined, the value is returned in common variable CXOP . 

DELDEV 

This delete routine deletes an Item by linking around the 
item and disposing of the heap space used by the structure. 
Devices are kept in singly linked lists In the heap, XOPS 
are kept in an array In common; consequently, they require 
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no delete routine. 


13.5.5 Deleting Structures. 

DELRT operates similarly to CHANRT except that DELRT never Issues 
a call to add a new structure; It Issues calls only to the 
routine that finds the desired item and to the routine that 
deletes that Item. 


13.5.6 Listing Structures. 

LISTRT Is the routine that produces configuration listings. 
These listings may be produced at the station for viewing by the 
user or to a file to be read by another use of SYSJEN or for 
later reference. The routines used by LISTRT are FORM, SHOWDV , 
and LIST2. LIST2 is a continuation of LISTRT, which calls 
FRMXOP. These routines all call DUMYUP and LOOK which transfer 
text from the JENDAT file to the output buffer, eliminating 
string constants from the program. All of these routines call 
ADDHEX, ADDNAM, ADDNMB, and ADDPAT for string operations. DISPAT 
is called by all of these routines. It directs the output to 
either a file or the interactive device. If the program is. In 
the INTERACTIVE phase, the user sees the list; otherwise, the 
information is written to the CONFIG file. 

FORM 

FORM is used to fill in the answers to system questions. 
The type of question is found in array TQ, and the answer is 
added to a line of text read from the JENDAT file. 

LOOK 

LOOK reads a record from JENDAT, scans for the question mark 
in the text field, and initializes common variable BC to 
point to the question mark. Thus, answers may be encoded 
into the field . 

SHOWDV 

SHOWDV uses the logic of FORMDV to show all pertinent 
information about a device. 

FORMDV, FRMXOP 

FORMDV, and FRMXOP build the lines of text for displaying 
information about devices and XOPs to the configuration file 
or the user. 

FILLTB 

FILLTB is called after every system question is answered to 
update the question-answered table by implication. This 
routine uses common arrays YESINF and NOINF to answer 
certain questions for the user. 
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13.6 DETAILS OF THE BUILDING PHASE 

The flow through the BUILD phase Is linear. The first module 
called Is INITBL, which Initializes data structures that cannot 
be Initialized as long as the user can change his mind. The next 
routine called Is SYSJCA, which defines the system job. BLDWSR 
Is called to build Interrupt decoder tables. PDTBLD builds the 
PDTs . BLDSSB builds the SSBs. If communications devices are 
genned, BLDSWS and BLDDSR build the files required to build the 
communications software scheduler and communications device 
service routines, respectively. 

Throughout the process, all of these routines and BILDRT Itself 
depend heavily on the COPY routine. Although the COPY routine Is 
physically split Into 17 different routines, they all function as 
one routine. COPY Is used to access data In the JENDAT file, 
process It as specified In that file, and output It to the files 
for the built system. 

INITBL 

INITBL marks the SVCs required by system common and system 
disk In addition to those that were chosen by the user. The 
OPSVC array Is then filled by assigning the values Indicated 
by SVCGRP and the DESVC array. The use of each Interrupt 
level Is then determined (INTUSE) and expansion chassis .use 
Is marked In array CHSINUSE. INITBL marks the combinations 
of communications boards and protocols which have been 
chosen by the user. This Information will be saved In the 
COMSTATUS array. If communications devices have been 
genned, INITBL will call INITCM to create all files required 
for communications link. Finally, INITBL will set the flags 
used o load the DSR overlays. 

SYSJCA 

SYSJCA scans the job list, looking for a job with an ID of 
0. If such a job exists, it becomes the system job. If 
this job does not exist. It Is created. This routine Is 
used to prevent special case coding for the system job in 
later routines . 

BLDWSR 

BLDWSR first builds the workspaces for the Interrupt 
decoder. This routine uses array INTUSE, which was 
Initialized in INITBL to decide what devices are available 
at each interrupt level. The workspace Is different for 
single device per interrupt, multiple device per interrupt, 
one or more asynchronous TILINE controllers per interrupt, 
and each of the expansion chassis. If an Interrupt level 
has more than one device, a multiple interrupt decoder table 
Is built for that Interrupt level. The table consists of 
Interrupt bit positions used for polling In the Interrupt 
decoder, and interrupt vector pointers. The table is of 
variable length. If an Interrupt level has one or more 
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asynchronous TILINE controllers, a multiple Interface table 
Is built. This table consists of the controller address and 
a pointer to the table of channel entries. The table of 
channel entries consists of the Interrupt vector pointers 
and the controller channel number. If a device has been 
defined on an expansion chassis, a table of Interrupt vector 
pointers for that chassis Is built. The size of the table 
Is 24 entries. Then, all Interrupt vectors are built, one 
for each device that shared an interrupt level on the main 
chassis and each device on an expansion chassis. 

PDTBLD 

PDTBLD is the main driver used In building PDTs. Note, 
however, that PDTFIL builds the fields needed to fill In the 
template kept in the JENDAT file, and PDTGO calls for the 
correct pieces of the template that are kept in the JENDAT 
file. PDTBLD sets either a flag In the common variable 
DCODE to Indicate that the current device Is the first 
device of a multiple drive controller, or a flag In common 
variable CASFLAG, to Indicate that the current device Is a 
cassette drive. PDTBLD also chooses the correct name to be 
used In filling the PDT template. PDTBLD Is also 
responsible for producing the trailer equate for the end of 
the PDT chain. Note that this trailer equate Is not 
produced If RTS is present. PDTFIL defines the values of 
flag words, labels, and special constants used in filling 
the template. These Include the device type flags, device 
status flags, the address, and the interrupt level. PDTGO 
decides where to begin copying In the JENDAT file. Some 
PDTs have no extensions, while others have as many as three. 

BLDSSB 

BLDSSB builds the SGB In the system table area, then builds 
SSBs for the segment management table area, file management 
table area, system root, and system common. The fields that 
must be Initialized are the link field, run-time ID, segment 
attributes, use count, segment group block pointer, segment 
beet address, and length of the segment. This routine 
Initializes these fields and calls the correct copy routine 
to build the SSBs of the STA. 
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13.7 JENDAT FILE 


SYSJEN maintains a large amount of data in the JENDAT file, which 
is a random file of Pascal records. The definition of the record 
type is as follows: 


TYPE GENMSG 


RECORD 

DEF : INTEGER; 

AAT : INTEGER; 

LB : INTEGER; 

UB ; INTEGER; 

NEXT ; INTEGER; 

LEN : INTEGER; 

TXT : PACKED ARRAY [1..76] OF CHAR END; 


The uses of each field are described first for the INTERACTIVE 
phase of SYSJEN and then for the BUILD phase. (The uses differ 
greatly.) Since the field names are based on their original uses 
in the INTERACTIVE phase, they do not accurately portray their 
uses in the BUILD phase. The names were chosen from the 
following uses of each field: 

Name Use 


DEF Default answer 

AAT Acceptable answer type 

LB Lower bound on answers 

UB Upper bound on answers 

NEXT Record number that logically follows 

LEN Length of the text that follows 

TXT Message text 


13.7.1 Interactive Use of the JENDAT File. 


The length field is used in the call block as the number of 
characters to be written. The text field contains the message to 
be written to the user's screen. Five types of questions asked 
by sysgen determine how the fields of the record are to be used. 
The types of questions asked are as follows: 

* Number questions 

* Name questions 

* Element questions 

* Pathname questions 
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* YES/NO questions 
13.7.1.1 Number Questions. 

Number questions use the default field to find the answer to be 
used if the user hits the RETURN key in response to a 
quest ion . 63No conversion is necessary. The value in the AAT 
field signifies the following: 

0 = any numerical answer is acceptable 

1 = any number greater than LB is acceptable 

2 = any number X such that LB <= X <= UB is acceptable 

3 = only LB or UB is acceptable 

This scheme allows the ASKNMB routine to determine the validity 
of answers without special case code for each question that 
requires a number answer. If only one of three or more 
noncontiguous numbers are acceptable, special case code is still 
r equl red . 


Consider the following example: 

REC # DEF AAT LB UB NEXT LEN TXT 

20 60 3 50 60 21 20 LINE FREQUENCY? (60) 


Record number 20 asks for the frequency of the line voltage. The 
default answer is 60. The default is always Included in 
parentheses in the text to Inform the user of the default. Since 
AAT = 3, the only acceptable answers are 50 or 60. The length of 
the text string to be written is 20 characters. This permits the 
response to be accepted directly after the question, without 
scanning the text string. The NEXT field indicates that if the 
user responds by entering a ? or Incorrectly answers the 
question, the longer form of the question is at location 21. 
This permits many changes to be made to the JENDAT file with no 
changes in program logic, and recompiling is not necessary. 

Often, several records are logically followed by the same record. 
Such is the case when, in answering the second question, the user 
Incorrectly defines the Interrupt levels. All of these error 
messages may be provided with the same text, as shown in the 
following example. (Note that all of the text will not fit 
across the page in this example.) 


REC # DEF AAT LB 

179 9 2 3 

REC # DEF AAT LB 

180 723 


UB NEXT LEN TXT 

15 185 49 WHAT IS 

UB NEXT LEN TXT 

15 185 46 WHAT IS 


THE INTERRUPT LEVEL 
THE INTERRUPT LEVEL 


This example asks for the interrupt level of a tape unit and then 
the Interrupt level of a flexible diskette. The default is 
either 9 or 7. The accep table answe rs are the same, but the 
question lengths differ slightly. Notice that the next logical 
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record is the same for each question. Seven other questions also 
use the same text at record 165. 

Often, the value of NEXT Is 0. This indicates that the current 
record is the last of a chain. This will be the last record that 
the current request will display. 

13.7.1.2 Name Questions. 

Name questions assume that only the first character of the answer 
is significant. The default contains the ordinal of the first 
character of the name. The value of AAT is as follows: 0 

indicates that any answer is acceptable, 1 indicates that only 
ORD(LB) or ORD(UB) is acceptable, and 2 indicates that the user 
must answer the question. 

If AAT is 1 and DEF is 0, no default exists. As a result, the 
question (or a similar question) is asked until it is answered 
correctly. The following example asks for the type of line 
printer being defined. The user is expected to answer either 
serial or parallel. The default is serial. The ordinal of S is 
83, and the ordinal of P is 70. Thus the user may hit the RETURN 
key to indicate serial (the default). Any answer except a RETURN 
or words that begin in S or P are treated as incorrect answers. 

REG # DEF AAT LB UB NEXT LEN TXT 

272 83 1 70 83 273 20 PRINT MODE? (SERIAL) 

In the next example, the user is asked for the workspace label of 
a special DSR. Any answer is acceptable, but note that an answer 
must be given. 

REG # DEF AAT LB UB NEXT LEN TXT 

344 0200 345 14 DSR WORKSPAGE? 

13.7.1.3 Element Questions. 

Element questions use the default answer if AAT is 1 and the user 
hits the RETURN key in response to the answer. Otherwise the 
value of NEXT points to a list of valid answers. 

The list can then be searched using ASKELM, which compares the 
user response to the TXT (message TEXT). If a match is found, 
the DEF field is returned as the answer. Otherwise, the next 
logical record is searched. (The next logical record is pointed 
to by the field NEXT. If NEXT is 0, this signifies the end of 
the list). This process is continued until a match is found or 
the GMD key is pressed. If an invalid answer is entered, then 
the longer form of question is asked. 

An example of an element question is one that asks baud rate, as 
follows : 
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REC # DEF ATT LB UB NEXT LEN TXT 
1820 0000 1822 10 BAUD RATE? 

The next physical record of the file has the first line of the 
explanation of the question and records starting at 1822 have the 
valid options. The entries for the valid responses Include as 
the DEF field the internal value needed by SYSJEN. 


NOTE 

The first line of the longer question must be 
physically after the short question. The 
valid answers must be logically after the 
short form. This applies only for the 
element questions. 


WARNING 

The Internal value (the DEF field) usually 
plays a significant role during the build 
(and sometimes the inquiry phase) of Sysgen. 
When adding or deleting elements from these 
lists, great caution should be used. 


13.7.1.4 Pathname Questions. 

Some questions are answered by pathnames. These questions use 
the logic of the name questions. When a valid name has been 
entered, (almost anything Is an acceptable name), the syntax of 
pathnames Is checked. Thus, no special entries are made In the 
file. In the following example, the user Is forced to enter a 
name. The syntax requirements are treated in no special way In 
the JENDAT file; only the text gives any Indication of the 
requirements of the answer. 

REC# DEF AAT LB UB NEXT LEN TXT 
870 0200 867 25 APPLICATION PROGRAM FILE? 

In the following example (defining the KSB for a special device), 
the user Is not forced to answer the question; this means that 
the device does not have a keyboard. 

REC# DEF AAT LB UB NEXT LEN TXT 
337 0000 338 11 KSB? (NONE) 
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13.7.1.5 Yes/No Questions. 

Yes/No questions have as default answers the Internal Pascal 
representation of true and false, 1 and 0. The value of AAT is 
as follows: 0 indicates that a default exists, 1 Indicates that 

no default exists and the user must answer. 

In the following example, the user Is defining a line printer. 
The question determines whether an extended character set Is 
available on that printer. 

REC # DEF AAT LB UB NEXT LEN TXT 

277 0000 278 14 EXTENDED? (NO) 

The default Is NO, and the user may press RETURN to get the 
default . 


13.7.2 BUILD Use of the JENDAT File. 

The JENDAT file Is predominantly used for building source code In 
the various modules that describe the system being generated by 
SYSJEN In the BUILD phase. The DEF field Is used as follows: If 

DEF Is 0, no processing Is required on the field; If DEF Is 1, 

AAT contains the type of modification that Is required. This 
value is used as the case statement variable of the COPY routines 
In SYSGEN. The use of the values of NEXT and LEN In the BUILD 
phase Is similar to their use In the INTERACTIVE phase. The 

remaining fields are of variable usage. The LB field Is almost 
always a pointer into the record. This value Is the column 

number of the first column that requires modification. In the 

example that follows, a label Is Inserted on a PDT. 

REC # DEF AAT LB UB NEXT LEN TXT 

378 1 0 3 0 379 13 PS EQU $ 

The DEF flag signals that the record must be modified. Case 0 Is 
used to Indicate adding the current device name into location LB. 
If the current device Is DSOl , this name Is Inserted at column 3 
and the record is modified as follows: 

PSDSOl EQU $ 

Generally, the UB field Is 0. However, It is sometimes used to 
mark a second column for modifications, as in the following 
example where an Interrupt vector Is being defined. 

REC # DEF AAT LB UB NEXT LEN TXT 

594 1 29 15 29 0 57 IV DATA ,SG3BGN,MP 

The device name is added at column 15, and an offset determined 
by the device type Is added at location 30. Internal logic also 
adds the name at column 3 and a field determined by the device 
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type at column 13. If the device type were VDT and the current 
name were ST16, the record would be modified as follows: 

IVST16 DATA KBST 1 6 , SG3BGN ,MPSTl6 

Sometimes the UB field does not hold a location In a specific 
record; Instead, It holds the current location In a section of 
records. For example, consider building the expansion chassis 
Interrupt decoder table. This table Is 24 records long, each 
containing either 0 or a label of an interrupt vector (as in the 
previous example). 

REG /if DEF AAT LB UB NEXT LEN TXT 

830 1 28 15 6 831 14 DATA IV 

In this example the UB signifies that the user Is building the 
seventh entry, the entry for Interrupt position 6. If the 
current device name was ST16, the seventh entry in the Interrupt 
table would become: 

DATA IVST16 

This use of UB Is prevalent In the table building portions of 
sysgen, although Its use as a column number Is more common. The 
only accurate means of determining Its use Is to examine the 
source in the COPY modules. 


13.7.3 Sample Copy Module. 

The following copy module Indicates the BUILD usage from the 
SYSJEN program. The entries are divided into groups of ten to 
simplify the requirements on the compiler. The COPY module has a 
case statement that uses the AAT field .divided by ten to 
determine which sub-COPY module to call to process the record. 
The ATT field is a hexadecimal number. To determine which sub- 
COPY module Is going to be used, convert ATT to decimal and 
divide by ten. The example given determines whether to include 
the given record in the link stream. The record In question 
should be Included if the system is a DNOS/D. 

REC # DEF AAT LB UB NEXT LEN TXT 
1621 1 5F 0 0 1622 20 PHASE 3,CFDF0V 

The AAT field of 5F Indicates that case number 95 of the COPY 
module is called to process this record. The code is taken from 
C0PY9 . 
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BEGIN 

DISK := QANS [ DISKQST] ; 

KIF ; = QANS[KIFQST] ; 

CD := QANS[CDFQST] ; 

FM := QANS[FMQST]; 

CASE JMSG.AAT MOD 10 OF 

0 : PRFLAG := QANS [ EXFQST ] ; 

1 : PRFLAG := NOT FM; 

2 : PRFLAG := NOT CD; 

3 : PRFLAG := FM; 

4 : PRFLAG := CD; 

5 : PRFLAG := DISK; 

6 : PRFLAG := NOT DISK; 

7 ; PRFLAG ;= NOT KIF; 

8 : PRFLAG ;= KIF; 

9 ; PRFLAG ;= NOT QANS [ EXFQST ] ; 

OTHERWISE ; END; 

END; 

The variable PRFLAG Indicates that the record should be printed 
if the value is true; otherwise it should not be printed. 


13.8 JENDAT EDITOR 

A special editing program is available to the DNOS development 
staff to maintain and modify the JENDAT file. This editing 
program is documented in the section on DNOS tools. 
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SECTION 14 

LOGGING AND ACCOUNTING 


14.1 LOGGING AND ACCOUNTING FUNCTIONS 

The DNOS logging system logs information to the system log files 
(.S$L0G1 and .S$L0G2) and an optionally specified log device. 
The log is used to Inform the operator or user of the state of 
the hardware and/or operating system. The log contains the 
following types of messages: 

* Device errors with the controller Images before and 
after an operation 

* Device errors with the offending call block 

* Abnormal task termination 

* Statistics from a DSR 

* Operating system Informative messages 

* User messages (from SVC >21) 

* Cache memory errors 

* Memory parity errors 

The DNOS accounting system logs information concerning use of 
system resources by user tasks to the system accounting files 
(.S$ACT1 and .S$ACT2). Entries are made for the following 
eve n t s : 

* Job initialization 

* Task termination 

* Job termination 

* Spooler device use 

* Initial program load (IPL) 

* User-defined (from SVC >47) 
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14.2 LOGGING AND ACCOUNTING TASKS 

The logging and accounting systems each have a queue server task 
to write data to the disk files. Whenever data is to be written 
to either the log or accounting files, an entry containing the 
data is put on the appropriate queue to be processed by the queue 
server. Since the function of writing data to the disk files is 
similar in both queue servers, several subroutines are shared 
between the tasks. If errors are encountered while writing to 
the files, then a message is generated for the log device and the 
attention device. 


14.2.1 LGFORM. 

The system log formatter task (LGFORM) serves the system log 
queue. This queue has system log blocks (SLBs) generated by user 
tasks using SVC >21 and from a variety of operating system 
sources . 

LGFORM first ensures that logging is functional. It then 
dequeues one entry after another until the queue is empty. For 
each log entry, LGFORM builds one or more lines of system log 
text and outputs it to the system log file (one of two possible 
system files) and, optionally, to a system log device. 

Since the log queue is a finite limit, there may be times when 
more messages are sent to the queue than will fit. In that case, 
DNOS increments a lost message count in the newest entry on the 
log queue. When LGFORM processes a log entry, it checks the lost 
message count. If it is greater than zero, LGFORM outputs a 
message showing how many log entries were lost. 

Other error conditions are also monitored and reported. If the 
files and/or log device should become inoperative, a message is 
sent to the attention device specified during system generation. 
When one of the log files becomes full, a message is also sent to 
the attention device. The alternate file will then become the 
log file in use. 


14.2.2 LGACCT. 

LGACCT is the task that processes the accounting queue. For each 
entry on the accounting queue, LGACCT builds an accounting record 
and writes it to the accounting file that is currently in use. 
Like the log files, when one accounting file is filled, LGACCT 
switches to the other accounting file. Errors in the accounting 
files are also reported to the log attention device. Unlike the 
log files, the accounting files contain binary data instead of 
text. For information on processing the data in the accounting 
files see the DNOS System Prog ramme r s Guide. 
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14.3 SUPPORT ROUTINES 

Since many of the functions of the log and accounting system are 
similar, many of the following routines are linked Into both 
systems. 

LGALUN 

LGALUN Is used to assign a LUNO to the output file currently 
In use. It may be used for either the log files or the 
accounting flies. 

LGATTN 

LGATTN Is used to write a message to the attention device If 
one has been specified. 

LGCHEK 

If an error Is encountered while writing to the log files 
and log device, then LGCHEK will delay and continue retrying 
the request until It succeeds. 

LGSWTH 

When an output file fills up, LGSWTH Is called to close the 
current file and open the other file. The new file Is 
marked as the current file. If there Is a task specified to 
process the flies, then that task Is bid after the files are 
switched. If both a system-supplied task and a user-defined 
task are supplied, the system-supplied task Is bid first. 
This routine can be used for either the log or accounting 
flies . 

LGWACC 

LGWACC outputs an accounting record to the current 
accounting file. 

LGWDEV 

LGWDEV writes a message to a device. It may be used for the 
log device or the attention device. 

LGWLOG 

LGWLOG outputs a log message to the current log file. It 
also ensures that the log flies are switched when one fills 
up and that the message goes to the log device If one has 
been specified. 


14.4 MISCELLANEOUS MODULES 

Several modules are used throughout DNOS to generate log entries. 
LGACHN 

LGACHN Is a task that runs In the spooler job. It receives 
IPC messages from the spooler system containing device 
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accounting records. LGACHN is responsible for putting those 
accounting records on the accounting queue. 


LGDEV 

LGDEV is a routine in the DNOS kernel that is used to 
generate log messages for device errors. It calls LGQBLK 
after setting up a device message. 

LGGLOG 

LGGLOG is a task that is Invoked during system restart to 
read the crash dump from the previous crash and retrieve any 
log messages that were generated before the crash but did 
not make It to the log file. Those messages are then 
written to the log file. 

LGQACC 

LGQACC Is a kernel routine that queues an accounting record 
to the accounting queue. 

LGQBLK 

LGQBLK Is a kernel routine that queues a log message to the 
log queue. 

LGRCRT 

LGRCRT Is a task that Is Invoked when the log or accounting 
files need to be created or recreated. When recreating a 
pair of files, it ensures that the new files are created 
before destroying the old files. 

LGSVC 

LGSVC Is the module In the DNOS kernel that processes user 
log message SVCs (SVC >21). It generates a log record to be 
queued to the log queue. 

PMACCT 

PMACCT Is the kernel routine that processes the accounting 
SVCs (SVCs >47 and >49). For the log accounting entry SVC 
(>47), It creates an accounting record and queues it to the 
accounting queue. For the get accounting Information SVC 
(>49), It returns the accounting Information for the 
requested task in the call block. 
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SECTION 15 

DNOS PERFORMANCE PACKAGE 


15.1 OVERVIEW 


The DNOS Performance Package uses the 990/12 writable control 
store (WCS) to enhance DNOS speed. This section describes the 
WCS component and also describes the way DNOS operates without 
the WCS component. 


15.2 DNOS SOURCE CONVENTIONS 


DNOS source has two components that enable use of WCS for speed 
enhancement. These are a set of XOPs and a routine in the 
NUCLEUS source directory named NFMAT . For a number of system 
routines, the execution takes place In WCS when the performance 
package is available and otherwise, takes place In memory 
(referred to as default code). The access to the system routines 
Is via XOP Instructions, placed Into the DNOS source code by 
macros. These macros are described briefly In the section on 
naming and coding conventions. In addition, NFTBID ensures that 
all system tasks that are bid have their WCS status bits turned 
on. This will cause routine calls to go to microcode. 

The XOP assignments are as follows. 


XOP 

10, R1 

RPPRCK 

XOP 

10 ,R2 

RPSGCK 

XOP 

10, R3 

NFRTA 

XOP 

10, R4 

NFGTA 

XOP 

10 ,R5 

NFGTAO 

XOP 

11 ,RX 

NFPOPX 

XOP 

12 ,RX 

NFPSHX 


It Is Important to note that the microcode assumes that bit 11 of 
the instruction is a zero. This is used to quickly decide what 
map file the caller is In. This means that only direct register 
addressing can be used in the XOP instructions. Any violation of 
this rule generates unpredictable results. 

NFMAT is a data area that starts at location >E0. NFMAT is used 
to tell the microcode the location of things it wants to access 
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In memory. For example, It cont^ains the address of JCASTR. 
Since the microcode uses Its own equates, the order of the data 
In NFMAT must not be changed without changing both the default 
and performance microcode modules. Data used to crash and 
provide addresses for the default microcode starts at location 
>100. Since the microcode can only map an eight bit constant, 
this area is addressed by shifting an eight bit number to the 
left one bit and using that as the* address. For this reason, 
some addresses have equates In the microcode that are only half 
of their expected value. This also means that If new data Is 
added after >100, the corresponding equate In the microcode must 
be divided by two to force It Into eight bits and multiplied by 
two to generate the correct value. The end of NFMAT contains a 
set of ASSUME statements. These ASSUME macros are needed because 
the microcode will reference fields within a block (like TSBMLl). 
If these assumes should fail, then the equates In the default and 
performance code must be changed. 

If the microcode should ever need to crash, the PC will be placed 
Into Rll and the crash code written to location >104. The 
program will then return out of microcode at location >100 which 
contains a BLWP to NFCRSH. 


15.3 MICROCODE CHARACTERISTICS 


The microcode Is divided Into two modules: the performance code 
and the default code. The performance code Is used to speed up 
DNOS and the default colde provides an Interface when performance 
code Is not Installed so that a 990/12 can execute XOPs 
efficiently. XOPs are decoded In the following manner: 


1. The XOP instruction is vectored into WCS 

2. The XOP level provides a first level of decoding 

3. The correct routine is found from a branch table 


The default control store Is used so that XOPs can be executed on 
a 990/12 quickly. Since It is always loaded. It Is linked in 
with the IPL procedure. If SLWCS finds no WCS Image file on 
disk. It moves the default code Into the WCS segment. Located 
before the WCS object Is a module called PFWCSO. This module 
simulates the overhead found in an Image file. It contains the 
number of microwords In the file, the start address, and other 
information. If default code Is being changed, PFWCSO must be 
changed to reflect the new length. Equates for new symbols must 
also be added to the microcode. 
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15.4 MICROCODE CODING CONVENTIONS 

Th Is section describes the standard conventions used to write 
microcode. It specifies the .syntax, labels, and comments that 
microcode should contain. It is assumed that the reader has read 
the 990/12 Microcode Development System Programmer's Guide or 
that he knows 990/12 microcode language. 


15.4.1 Standard Syntax For Microcode States. 

Since the microassembler does not specify an order in which 
microcode mnemonics are written, an informal standard has been 
adopted for DNOS microcode. This order makes the microcode 
states more orderly and facilitates reading. The format of a 
s t a t e i s : 

LABEL: READ, 

ALUI. XAC<A+B, 

A<ABUS ABUSKWK R( 2 ) , 

B<BBUS BBUS<CBUS, 

CBUS<MDI , 

ABUS2<SUM AREG<ABUS, 

MAP<MC MC<MC+2, 

MDKBTL, 

IF. ALU-EQ TRUE JUMP GTAIOO 


The label is put at the top of the state. After the label comes 
the memory I/O mnemonic. On the next line, the ALU form is 
specified followed by the ALU destination and the operands. 
Next, the A operand is traced from the ALU to its source (in this 
case WK R2). The B operand is then traced from the ALU to its 
source (the MDI). The ABUS phase two source and destination are 
then given (the SUM BUS and AREG respectively). After that, the 
destination of a memory read is given (the MDI in this case). 
Following that line, any conditional or unconditional jumps are 
specified (IF.). 


15.4.2 Labeling Conventions. 

Whenever possible, labels in the microcode correspond to the 
labels in the assembly language version of the module. If the 
microcode being written does not have equivalent assembly code 
(like for interrupt return code), then descriptive labels must be 
used . 
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15.4.3 Commenting Conventions. 

Comments have two parts. The first part of a comment is the 
assembly language code being emulated. For example, when 
emulating an AI R4,STALNK instruction, AI R4,STALNK should be in 
the comments. The second part is just the normal comment put in 
to clarify what is happening. It is also advisable that the 
programmer should stop periodically in the code and write a 
paragraph that describes what data is in what registers. Between 
the labeling conventions and the commenting conventions, it 
should be relatively easy for a programmer to read microcode when 
he has the corresponding assembly language available. 


15.4.4 Common Routines. 

There are a number of routines provided in the microcode to 
perform common functions. The programmer may use them or, if 
faster, execute them inside his own states. The routines are: 

NFCRSH 

lAQZERO 

BADXOP 

ERREX 

CDUMP 

NFCRSH is used by the microcode to cause a crash. It assumes 
that the MDO contains the crash code. The routine writes the 
crash code to >104 and then branches to >100 to crash. lAQZERO 
is used to end an instruction. It assumes that the next 
instruction address is mapped and that the PC points two beyond 
that. The routine reads the instruction into the IR and returns. 
BADXOP is used to signal an illegal XOP . It sets an illegal 
instruction interrupt and aborts. ERREX is used to take error 
returns. It assumes that RO contains the error code and that the 
map and PC point to the address of the word containing the error 
return. The routine checks the error return and takes the 
correct action. This routine is similar to NFPOPO. CDUMP is 
used to dump the cache. It loads the MC from RF 15 (where a copy 
of the WP is kept) and dumps the cache. This routine destroys 
the MC. 

All routines mentioned above except CDUMP are executed via the 
JUMP mnemonic. CDUMP is executed using the CALL mnemonic. 

15.4.5 Debugging. 

Most microcode debugging is done by code reading. The solution 
is usually obvious once the error is isolated. In cases where 
code reading of both assembly language and microcode does not 
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Isolate the error It may be useful to get a trace of the 
microcode. This can be done using a logic analyzer. If a logic 
analyzer is used, Table 15-1 shows where to connect the analyzer 
to the AU board of the system. The table only shows the location 
of the microaddress bus. To look at other signals, consult the 
schematic found in Processors and Memories Vol. II, Part Number 
0945421-9702 *B. 

Table 15-1 Location of the Microaddress Bus 


Loca t i on 

Pin 

Function 


Y5 

8 

Clock 


XIO 

4 

Ground 


DIO 

8 

UPC 

Bit 

1 1 

DIO 

7 

UPC 

Bit 

10 

DIO 

6 

UPC 

Bit 

9 

DIO 

5 

UPC 

Bit 

8 

DIO 

4 

UPC 

Bit 

7 

DIO 

3 

UPC 

Bit 

6 

DIO 

2 

UPC 

Bit 

5 

DIO 

1 

UPC 

Bit 

4 

Dll 

23 

UPC 

Bit 

3 

Dll 

22 

UPC 

Bit 

2 

D12 

21 

UPC 

Bit 

1 

H8 

12 

UPC 

Bit 

0 
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SECTION 16 

DEVELOPMENT AND ANALYSIS TOOLS 


16.1 OVERVIEW 

The tools described in this section are for two purposes: DNOS 
development and DNOS analysis. The tools described first are 
shipped with DNOS. These Include SRFI, TIGRESS, the System 
Debugger and PICT. The JENDAT editor is currently available only 
for Texas Instruments internal use. 


16.2 SHOW RELATIVE TO FILE INTERACTIVELY UTILITY (SRFI) 

The SRFI command displays and/or modifies the internal contents 
of files to VDT terminals. It assumes that the user has 
knowledge of the file structures Involved. The file is accessed 
by physical records rather than logical records. The command is 
Invoked by entering SRFI. Respond to the prompts as follows: 

SHOW RELATIVE TO FILE INTERACTIVELY 
FILE NAME: 

EDIT ACCESS? ; NO 

PROMPT DETAILS: 

FILE NAME; The name of the file to be d 1 s p lay e d /mod i f i ed . 

EDIT ACCESS?: Determines file access privileges. NO gives 
read only access, while YES gives exclusive write 
access. If no editing is desired, take the default 
NO response. 

This utility works only on VDT terminals. The user is prompted 
for the record number by the utility. The utility starts with 
record 0 being displayed. The user may enter the record number 
desired in the field marked RECORD: 0000. If the record exists, 
it is displayed. If it does not exist, a >0030 error will be 

displayed as ERR: 0030. The FI key moves forward through the 

file displaying data and updating the data displayed, while F2 

moves backward through the file. If the entire record will not 

fit on the screen, the user may advance the data up through the 
data window by pressing the Previous Line key. The Next Line key 
moves the data down through the window. 
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To enter the edit mode press the F3 key. The cursor will move 
into the data fields at the upper left field of the data being 
displayed. The cursor can be moved through the data fields one 
at a time by pressing the Return key. This will advance the 
cursor to the next editable field. Previous Line will move the 
cursor up one line if it is available. Next Line will move the 
cursor down one line If it Is available. Previous Field moves 
back one editable field. If the movement desired is not possible 
the cursor remains In the current field. The window will be 
moved across the file record as required to display large 
records. When the user moves the cursor through fields, the 
ASCII representation of the data will be modified to reflect the 
data that was In the field when the cursor left the field. 

The data entered Is not written to the file until the Enter key 
is pressed. SRFI then returns to the show mode on the same 
record that was being edited. The user may abort the update by 
pressing the Command key, which returns the user to show mode. 
The FI and F2 keys also abort the edit before moving to the 
appropriate record In show mode. 

Note that this utility provides a convenient means of recovering 
from >15 errors. Position the record containing the disk error 
on the screen, press F8 and then Enter. If the write was 
successful the error field will go to zero. Any data which may 
yet be Invalid because of the >15 error may then be edited for 
correction . 

It Is also possible to edit the ASCII representation fields by 
entering the F7 key. This positions the cursor on the equivalent 
field In ASCII mode. F6 returns the cursor to the hexadecimal 
representations . 


CAUTION 

The data returned Is 7-blt ASCII. The high 
order bit will be returned as binary 0. The 
user may inadvertently alter data by editing 
in the ASCII fields. 


16.3 THE TIGRESS TEST FACILITY 


The Tigress program is used to establish an environment and 
exercise a test program using SVCs to the operating system. 
Tigress allows the user to define strings and values in Tigress 
task memory, to Issue SVCs, to examine areas of Tigress task 
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memory, and to use a file of data for Input, 

Tigress can be used interactively with commands input from a 
terminal, commands echoed to a terminal, and display information 
output to a terminal. Tigress can also be used in a batch stream 
with input and data from files or various devices. 

Tigress is activated by direct task bid or by issuing the TIGR 
command to SCI. The command has the following prompts: 


TIGR 




EXECUTE TIGRESS 



COMMAND 

ACCESS NAME 

[ pathname @ ] 


LISTING 

ACCESS NAME 

[ pathname (3 ] 


DATA 

ACCESS NAME 

[ pathname @ ] 


ECHO 

ACCESS NAME 

[ pathname @ ] 



TASK ID 

Integer 

(A5) 


FIRST LUNO 

Integer 

(OAO) 

2ND TIGRESS NEEDED? 

yes /no 

(no) 

STOP ON 

END ACTION? 

yes /no 

(yes ) 

BUFFERED COMMAND ECHO? 

yes /no 

(no) 

PROMPT DETAILS: 





COMMAND ACCESS NAME 

This prompt requests the source of the commands to be Issued 
to Tigress. If a file name is used, input will be from that 
file. If the response is null, the terminal issuing the 
TIGR command is assumed to be the source of Tigress 
command s . 

LISTING ACCESS NAME 

If a file name is specified, output from Tigress display and 
status commands are placed in the file. If the response is 
null, the terminal Issuing the TIGR command is used for such 
listings. Messages output to the listing file are preceded 
by XXXX : where XXXX is the line number of the command 
causing the message to be printed. Messages generated by 
Tigress in response to I/O errors to any of its files are of 
the form XXXX:YY--msg where XXXX Is the line number of the 
command that was being processed, YY is an I/O error code, 
and msg is the Tigress message describing the error 
situation. An error count is kept, and a maximum of 25 
errors is allowed before Tigress terminates. If output is 
not desired, enter DUMY. 

DATA ACCESS NAME 

If a file name is specified here, that file can be used for 
data input using the third LUNO of the set assigned by the 
TIGR proc . 
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ECHO ACCESS NAME 

When a command Is parsed by Tigress, the command Is echoed 
for the user to see. If a file name Is specified for this 
prompt, the echo output goes to the file. If the response 
Is null, the echo goes to the terminal Issuing the TIGR 
command. This feature Is especially useful If commands are 
coming from a file and the user wants to watch the progress 
of the Tigress test at a terminal. If output Is not 
desired, enter DUMY. 

TASK ID 

The task ID specified Is that of the Tigress program to be 
used for the current tests. If you wish, you may put 
several versions of the program In the system program file, 
each with specific attributes needed for tests. 

FIRST LUNO 

Tigress uses four LUNOs to access the flies or devices 
specified for COMMAND ACCESS NAME, LISTING ACCESS NAME, DATA 
ACCESS NAME, and ECHO ACCESS NAME. The LUNOs are four 
sequential numbers, beginning with the FIRST LUNO prompt 
response. These LUNOs are assigned by the TIGR proc before 
activating Tigress and released by the TIGR proc after 
Tigress terminates. 

2ND TIGRESS NEEDED 

If the Tigress task Is to bid a second copy of Tigress, 
using Its own access name, enter YES. Otherwise, enter NO, 
A YES response will bring up a second screen of prompts for 
access names and task ID for the second copy of Tigress. 

STOP ON END ACTION 

If YES Is entered. Tigress will terminate If It encounters 
an error that causes It to go to end-action. If NO Is 
entered and Tigress goes Into end-action. It sets the 
command and list access names to be ME and processing 
resumes with commands from the terminal. 

BUFFERED COMMAND ECHO 

If buffered commands are to be executed with echo output, 
enter YES. This Is most useful when debugging a new command 
file. 


16.3.1 Details of Tigress Commands. 

Table 16-3 shows the set of Tigress commands and their required 
parameters. Table 16-1 shows the argument types used In 
describing the commands. 
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Table 16-1 Types of Arguments for Tigress Commands 
Type Meaning 


Address 

Number 


String 

Label 


Number or expression whose value Is a 
valid Tigress task address 
Decimal value whose first digit Is 

non-zero, hexadecimal value preceded 
by 0 or >, or an expression whose 
value is numeric 

Alphanumeric characters surrounded by 
quote marks (”) 

1 to 6 ASCII characters 


An expression Is any combination of numbers or addresses using 
addition or subtraction. The addresses used In an expression may 
be stated as labels that have been previously defined to have a 
numeric value. Arguments to the commands may also use signed 
numbers, preceding the number by a plus (+) or minus (-) sign. 
Indirect arguments can be specified by preceding the argument 
with an asterisk (*). In addition to labels defined by the user 
with the EQU command, there are a number of predefined labels. 
Table 16-2 lists and defines the predefined labels. 


Table 16-2 Predefined Labels for Tigress Commands 


Label Meaning 


ADDRND 

CMDSCB 

DATSCB 

ECHSCB 

LSTSCB 

NEWMEM 

PC 

RO - R15 
SVCB 

STK 


First Illegal (upper) Tigress address 
Address of SVC block used to read commands 

Address of SVC block used to read data file 

Address of SVC block used to write echo 

Address of SVC block used for listing file 

Start of memory acquired with GET command 
The record number of the current command 
Tigress user registers 0 through 15 
Address of start of the SVC block used by 
Tigress to Issue user specified SVCs 
Address of stack of arguments from last BRL 
command 


The labels In Table 16-2 can be used in the DSP command to find 
the location of special Tigress structures. These labels cannot 
be redefined by the user. 

The address space used by TIGRESS looks as follows: 
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+ + 

0000 I REGISTERS RO - R15 I 

I I 

0032 I SERVICE CALL CONTROL BLOCK | 

I I 

+ + 

? I USER DEFINABLE ADDRESS SPACE 1 

I I 

\/>/\/\/\/>/\/\/%/\/\/\/\/\/\/\/\/\ 

^/^/\/^/\/\/^/^/^/\/\/\/\/\/\/\/^/\ 

I 

+ 

X I FIRST INVALID ADDRESS | 



The entire set of command options Is listed In Table 16-3. In 
addition to these, users may specify a comment line In a command 
file by placing an asterisk In the first column of the line. 

The 3 letter command must begin In column 1 and the argument list 
must begin In column 5. Each argument, except strings, generates 
2 bytes of data. The commands are described In the paragraphs 
following the table. 
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Table 16-3 Tigress Commands 


Command 

Parameters 

BRL 

label [ . . . numbe r / addr e s s / s t r 1 ng ] 

DSP 

number , address 

END 


EQU 

string , numbe r 

GET 

number 

INC 

address, number 

INP 

address , number 1 , number 2 

JMP 

number 

JPB 

"label" 

JPF 

"label" 

LBL 

"string" 

MSG 

string 

MVI 

address, numberl ,number2[ , numbers 

MVS 

address 1 , number, address 2 

RBT 

address , number 

RTE 


RTN 


SBS 

address , number 

SBR 

address , number 

SBT 

address, number 

SCB 

number 1 , [ , number 2 ] 

SEI 

addr es s , number 1 ,number2[ , numbers 

SHI 

address , numbe rl ,number2[ , numbers 

SLI 

address, numberl ,number2[ , numbers 

SNI 

address, numberl ,number2[ , numbers 

SES 

address 1 , number , address 2 

SHS 

address 1 , number, address 2 

SLS 

address 1, number , address 2 

SNS 

addressl ,number,address2 

SVC 

[ numbe r , . • . ] 
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BRL [ label string ] 

The branch and link to subroutine command saves the current 
value of PC, builds an argument list in the stack area, and 
branches to a specified subroutine, (See also RTN and RTE.) 
For example, BRL SUB 1 , > 0 AGO , @ > 1 00 , A , B , 23 , " ABC" would cause 
subroutine SUBl to be called with a stack as follows: 

PC Location of the BRL command within the command file 

>0400 

@>100 Whatever 16 bit address this resolves to 
A Whatever this is equated to 

B Whatever this is equated to 

23 

>4142 AB 
>4320 C 

14 The length of the argument list in bytes 

The value of STK is changed to point to the length word (the 
14 in the above example). The stack Itself resides within 
the Tigress task area, but is not modifiable by the user. 
It is expected that a subroutine would pick up its arguments 
as f ollows : 

EQU "ARGl AD" , STK-*STK 
EQU "ARG2AD" , ARGl AD+2 

# 

EQU "ARGl" ,*ARG1AD 


NOTE 

(1) Subroutines may call other subroutines 
several levels deep if needed. However, the 
total stack area is 120 bytes. An error will 
occur if a BRL is attempted which will 
overflow the 120 bytes limit and the BRL will 
be Ignored. 

(2) Text strings may be passed as arguments. 
They are put directly in the stack with a 
blank at the end if the length would be odd. 
The subroutine must either be capable of 
determining the length or the length should 
be passed as a separate argument. Also, such 
strings will quickly consume the 120 bytes of 
stack space, so use this feature with 
discretion. Since a variable length string 
in the stack would make it inconvenient to 
find an argument which followed the string. 
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It is recommended that only the last argument 
(if any) of a subroutine be such a string, 

(3) The subroutine address (SUBl in the above 
example) must have been previously defined 
with an EQU command before the subroutine can 
be called. 


DSP number ,addres s 

This command displays the number of bytes specified, 
starting at the address specified. The address is rounded 
to an even numbered address if necessary. Memory is 
displayed in multiples of 8 words per line of output. Each 
line of output shows the memory address of the first word 
displayed, eight words of data in hexadecimal, and the same 
eight words of data in ASCII. 


END 

The END command is used to terminate execution of Tigress, 
A termination message is output, and control returns to the 
task that activated Tigress. 

EQU s t r ing , number 

This command is used to assign a value to a label. The 
label can then be used as a parameter or as part of an 
expression in other commands. The string specified is the 
label to be used, and the number specified (or expression 
that evaluates to a number) is the value retrieved whenever 
the label is used. 

GET number 

This command gets 32 times the number of bytes of memory to 
be Included in the Tigress address space. The address of 
the first word of this block of memory is equated to the 
string NEWMEM. Note that NEWMEM is undefined until this 
command is executed. On subsequent executions of the 
command, NEWMEM points to the start of the new block of 
memory acquired. 

INC address , number 

The number specified is added to the current value at the 
address specified. 

INP address , number 1 , number 2 

This command causes numberl bytes of data to be read from 
the data file into memory at the address specified, starting 
from record number2 of the file. 

JMP number 

This causes Tigress to execute next the command that is 
located at a distance specified by number. JMP 0 indicates 
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that this same command should be executed. JMP -1 Indicates 
that Tigress should proceed to the command preceding this 
command by two, JMP 3 indicates that the next two commands 
should be skipped. This command is not meaningful If 
command input is from a terminal. (Comments count as 
commands.) JMP is an unconditional command but can be used 
with the skip commands below to accomplish branching. 

JPB "label" 

The jump backward to label causes a jump back in the command 
file until an LBL command is found with the same string 
operand as is on the JPB command. For example, JPB "ABC" 
jumps back in the file until a command of LBL "ABC" is 
encountered. The operand must be in quotes since it is not 
entered in the symbol table. It is treated as an ASCII 
string. The string may be of any length, but only the first 
six characters are used in the comparison. 

JPF "label" 

The jump forward to label command works like JPB except that 
the jump is in the forward direction rather than backward 
through the command file. 

LBL "string" 

This command denotes a place for a destination of a- JPF or 
JPB command. The string may be from 1 to 6 characters long. 

MSG string 

The string specified is output to the listing file. This is 
useful for noting success or failure in a test stream and 
for documenting the test in progress. 

MVI addre s s , number 1 , number 2 [, numbe r 3 ... ] 

This command causes a move to the address specified of 
numberl bytes of data specified in number2 through the last 
parameter. Each argument creates two bytes of data. 
Example: MVI ADDR,1,>FF will move zero not >FF since the 

data value is >00FF. 

MVS address 1 , number 1 ,address2 

This command causes a move to addressl of numberl bytes from 
address2. 

RBT address , number 

This command resets (sets to zero) the bit at the position 
specified by the number argument in the word at the 
specified address. 
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RTE 

The return with error command returns from the current 
subroutine to the second command after the BRL which was 
last encountered. The stack is popped so that the value of 
STK is changed to the location of the saved argument list 
for the previous subroutine call (if any). 


RTN 

The return from subroutine command returns from the current 
subroutine to the first command after the BRL which was last 
encountered. As with RTE, the stack is popped. 

SBR address , number 

The SBR command tests the bit at the given position number 
in the specified address and skips the next command if the 
bit is reset (equal to zero). 

SBS address , number 

The SBS command tests the bit at the given position number 
in the word at the specified address and skips the next 
command if the bit is set to one. 

SBT address , number 

This command sets to 1 the bit at the given position number 
in the word at the specified address. 

SCB number 1 [, number 2 ] 

This command builds the SVC at the address specified by the 
first argument, with the argument list beginning at the 
second argument address, and executes the SVC. If only one 
argument is specified, then the currently existing SVC at 
that address is executed. (This is similar to the SVC 
command except that the address is specified instead of 
defaulting to location SVCB) 

SEI address, n urn berl ,number2[ , numbers. . . ] 

SHI address ,n urn berl ,number2[ , numbers. . . ] 

SLI address, n urn berl,n urn ber2[ , numbers . . . ] 

SNI address ,n urn berl ,number2[ , numbers. . . ] 

Each of these commands compares the string of length numberl at 
the address specified with the value expressed in number2 through 
the last argument. If the comparison succeeds, the next command 
is skipped. SEI causes a skip if the comparison is equal, SHI if 
the first argument is high, SLI if the first argument is low, and 
SNI if the first argument is not equal to the immediate data. 
These commands are not meaningful if command input is from a 
terminal . 
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SES address l,n urn her, address2 
SHS addr e s s 1 , number ,a ddre s s 2 
SLS address l,n urn ber,address2 
SNS addr e s s 1 ,numbe r , a ddr e s s 2 

Each of these commands compares the number of bytes specified at 
addressl with the data at address2. If the comparison succeeds, 
the next command is skipped, SES causes a skip if the comparison 
is equal, SHS if the first argument is high, SLS if the first 
argument is low, and SNS if the arguments are not equal. These 
commands are not meaningful if command input is from a terminal, 

SVC [ number , , , , ] 

If the argument list is null, the SVC currently at address 
SVCB is executed. If an argument list is presented, it 
replaces the data currently at SVCB, and the new SVC 
specified at SVCB is executed. 


16,3,2 Directives of Tigress, 

There are two directives which can be used to modify the manner 
in which Tigress reads and processes commands. These directives 
allow for buffering of Tigress commands to reduce file I/O 
Interference for test instructions and test data. Like commands 
they consist of 3 characters and must begin in column 1 with 
column 4 left blank. Columns 5 through 80 may contain comments 
and are Ignored, Directives are treated as commands and comments 
by the jump and skip commands. The directives are as follows: 

BUF 

Upon encountering this directive Tigress proceeds to read 
and buffer commands in its memory space. Approximately 200 
commands may be buffered. 


UNB 

Upon encountering this directive Tigress discontinues 
buffering commands and begins executing commands in memory 
beginning with the first command buffered. 

If a jump is made from a buffered command to a command outside 
the range of buffered commands the buffered mode is discontinued. 
If a jump is made into an area of buffered commands buffering 
mode is not initiated because Tigress did not encounter the BUF 
command. A BUF command following a BUF command but preceding the 
UNB command causes no action. An UNB command not proceeded by a 
BUF command causes no action. While in buffering mode any 
messages output by the MSG command will also be buffered. If MSG 
commands are included in a BUF-UNB block of commands then the 
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number of commands which may be buffered is reduced. Echo output 
while in buffer mode is suppressed. The DSP command output is 
not affected by the buffer mode of operation. 


16.3.3 User Defined Commands For Tigress. 

When Tigress encounters a command it searches its definition 
table and if the command is found a BLWP is made with the value 
of the command in the table being the address of the start of the 
code to be executed for that command. 

This method of implementing command execution enables the user to 
define his own command as if if it were a Tigress command. The 
procedure for doing this is to equate a 3 character label to a 
location at which code is to be executed. By using MVI commands 
the machine code is placed in memory. The last machine 
instruction must be a RTWP ( >0380 ). When the code is to be 
executed simply enter the label equated as a command. Tigress 
will search the table of equates and, finding the label, will 
process it as a command. This feature can be used for things 
such as initiate mode I/O where a separate call block must be 
built and executed. 


16.4 THE SYSTEM DEBUG UTILITY 

Since it is not always possible or convenient to use the SCI 
debugger or some other testing task, an interactive system debug 
program is available. This program allows the user to display 
and/or modify the workspace pointer, program counter, registers, 
and memory; to set as many as 16 software breakpoints in the code 
being debugged, and to step through the code one Instruction at a 
time. The program interacts with the user by doing I/O to a 911 
VDT or an ASR device. This program does not work on a 940 or 931 
VDT. 

About twenty-five commands are available for use with the debug 
program. Each command is specified by a single character. When 
the character is recognized as a command, the debug program calls 
the appropriate processor, that may in turn require additional 
parameters to be input. Whenever the program is expecting a 
command to be input, it prompts with a question mark (?)• 
Parameters that are entered are usually hexadecimal constants of 
up to four digits. A parameter is terminated by the fourth digit 
or by a period or Return key if less than four digits are 
specified. If an invalid digit is typed, the entire parameter is 
Ignored and may be reentered for most commands. In some cases. 
Invalid input causes the debug program to terminate. 
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16.4.1 Details of Debug Commands. 

The entire set of commands and parameters Is shown In Table 16-5. 
Each command Is detailed In the paragraphs that follow. Commands 
that allow the user to modify contents of some location first 
display the current value. If no value Is entered, no change Is 
made. Table 16-4 shows the command parameter types and their 
meanings. Brackets Indicate optional parameters. 


Table 16-4 Parameter Types for Debug Commands 
Type Meaning 

rel Offset relative to the current base address 

adr Absolute address In a task 

bt Beet bias address for the segment being 

addressed, located via map file Information 
carried In the TSB 


NOTE 


Breakpoints should not be used on 
Instructions that change CURMAP (for example. 
Instructions that move something to the OS 
label CURMAP) or on Instructions that change 
map file 0 (for example, LMF Rn,0). They 
must never be set on 
Instructions; that Is, XOP, 
number of /12 Instructions. 


Inter ruptable 
MOVS, and a 
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Table 16-5 Commands for System Debug Program 
Command Description 


A adr 1 [ b t adr 2 ] 
B rel 
C 

D adrl adr2[ bt 
E rell[ rel2] 

F 

I [adrl adr 2 ] 

J 

L 

M adr 
N 
0 
P 

Q 

Rn 

S adr 

U [ adr ] 

W 

X 

Z 

+ n m 
- n m 


Display and alter memory long 
distance 

Set a breakpoint relative to 
current base 

Display condition code In 
status register 
adr] Display memory long 
distance 

Examine locations relative to 
current base 

Display and alter following 
memory long distance 
Inspect local memory 
Show all local workspace registers 
List all Instruction breakpoints 
Display and alter contents of 
memory address 

Display and alter contents of 
next- memory address 
Set address for base of relative 
offsets 

Display and alter current program 
counter 

Quit debugging session 
Display and alter contents of 
register n (Hex) 

Set breakpoint at address In local 
address space 

Unset one or all breakpoints 
Display and alter address of 
workspace pointer 
Execute a single Instruction and 
stop 

Continue after current breakpoint 
Add the numbers n and m 
Subtract the number n from m 
Display a menu of all commands 


A - Display and alter memory long distance 

This command Is used to display and alter memory that Is not 
mapped Into the current task address space. The form of the 
command Is A xxxx bbbb yyyy where xxxx Is the address of 
the memory location to be displayed and altered and bbbb Is 
the starting beet bias of the segment In which the memory 
'location resides. The optional yyyy parameter specifies a 
logical address at which the segment bbbb Is supposed to 
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start. The appropriate beet bias can be determined from the 
map file Information in the task status block (TSB) or the 
segment status block (SSB) of the task being debugged. The 
bbbb and yyyy values default to their previous values. 

B “ Set a breakpoint relative to current base 

This command is valid only if the base address has been set 
correctly using the 0 command or the base address of the 
program being debugged is zero. The form of the command is 
B xxxx where xxxx is the offset from the base value at 
which a breakpoint should be set. When the program is 
executing and reaches the breakpoint, all current workspace 
registers are displayed; and the debug program prompts for a 
debug command. 

C - Display condition code in status register 

The form of this command is C=xxxx yyyy where xxxx is 
displayed as the current contents of the status register and 
yyyy is entered by the user as the new status register 
contents . 

D - Display memory long distance 

This command is used to Inspect a portion of memory that Is 
not mapped In the current task address space. The form of 
the command Is D xxxx yyyy bbbb zzzz where xxxx Is the 
starting address of the to memory to be displayed, yyyy Is 
the ending address, and bbbb Is the starting beet bias of 
the segment In which this portion of memory resides. The 
bbbb and zzzz default to their previous values. The 
optional zzzz specifies the starting logical address of the 
segment at bbbb. The beet bias can be retrieved from the 
task status block (TSB) of the task being debugged (use 
TSBMLl , TSBML2 , or TSBML3 depending on whether segment 1, 2, 
or 3 is being examined), or use the SSB to get the address. 
Like the I command, this command displays memory In blocks 
of >10 bytes, showing the starting address of each line of 
the dl splay . 

E - Examine locations relative to current base 

This command is valid only when the base address has been 
set using the 0 command or the starting address of the 
program being debugged Is zero. The form of the command Is 
E xxxx where xxxx is an offset from the current base. .The 
>20 bytes of memory starting at the offset Is displayed in 
the same format as used for the I command. 

F - Display and alter following memory location long distance 

This command can be used after an A command to examine the 
following memory location, similar to the N command is used 
after an M command. 
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I “ Inspect local memory 

This command allows the user to Inspect a range of memory 
locations in the local task address space. The form of the 
command is I xxxx yyyy where xxxx is the starting address 
of the range to be inspected and yyyy is the ending address 
of the range. If an invalid address is specified, the debug 
program will terminate. 

Both the starting address and ending address are optional. 
If neither is specified, >20 bytes of memory are displayed, 
starting at the current program counter address. The 

display shows >10 bytes per line of the display, preceding 
the data with the first address of the data. If only the 
starting address is specified, >20 bytes of memory are 
displayed, starting at that address. If both arguments are 
supplied, a multiple of >10 bytes is shown, starting at an 
even address and including at least the amount specified. 

J - Show all local workspace registers 

This command displays all workspace registers on one line of 
the display. 

L - List all instruction breakpoints 

This command lists all breakpoints currently set in the 

program. If an initial base address has been set using the 
0 command, this list Includes the relative offset from the 
base for each breakpoint as well as the absolute address of 
each breakpoint. 

M - Display and alter contents of memory address 

This displays M xxxx=yyyy zzzz where yyyy is the current 
value at local memory address xxxx and zzzz is the desired 
new value at that address. Only addresses currently mapped 
in the task space may be modified with this command. 

N - Display and alter contents of next memory address 

This command is used after an R, M, or another N instruction 

to display and/or alter the next memory address after the 

address examined previously. The command form is 
N xxxx=yyyy zzzz where xxxx is the address displayed by 

the debug program, yyyy is the current value, and zzzz Is 
the new value supplied by the user. 

0 - Set address for base of relative offsets 

The form of this command is 0 xxxx yyyy where xxxx is 
supplied by the debug program to show the current base and 
yyyy is supplied by the user as the new base. After this 
command has been used to specify the initial address of a 
program, the B and E commands can be used to set breakpoints 
and examine memory locations according to offsets from that 
base. This feature enables a user to work from an assembly 
language listing and easily determine where to stop 
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execution and where to examine data. 

P - Display and alter program counter 

This displays PC=xxxx yyyy where yyyy Is typed by the user 
to Indicate the new value desired for the program counter. 

Q - Quit debugging session 

The Q command terminates the debug program. If the debug 
program Is linked as part of the operating system, this 
causes the system to Idle. If linked with a user task, the 
Q command terminates that task. 

Rn - Display and alter register n 

This displays Rn=xxxx yyyy where yyyy Is typed by the user 
to Indicate the new value desired In register n. 

S - Set a breakpoint 

With this command, the user can set a breakpoint at any 
address currently mapped In the task space. The form of the 
command Is S xxxx where xxxx Is the local memory address 
at which execution should halt. When the breakpoint Is 

reached, all current workspace registers are displayed; and 
the debug program prompts for a debug command. 

U ~ Unset one or all breakpoints 

The form of this command Is U xxxx where xxxx Is the 
address at which a breakpoint has been set by either the S 
or the B command. The breakpoint specified Is unset. If 

xxxx Is not specified, all currently set breakpoints are 
unset • 

W - Display and alter workspace pointer 

This displays WP=xxxx yyyy where yyyy Is typed by the user 
to Indicate the new value desired for the workspace pointer. 

X - Execute a single Instruction 

This command allows the user to step through the program 
being debugged, one Instruction at a time. After one 
Instruction Is executed, all current workspace registers are 

displayed; and the debug program prompts for a debug 

command. This command may not work predictably when used on 
a breakpoint which Is currently set. 

Z - Continue after breakpoint 

When this command Is Issued, execution proceeds from the 
current breakpoint to the next breakpoint. If there Is any. 
Unless a U command Is used, the breakpoint that was just 
used remains In the code and can be reached again. 

+ - Add numbers 

The form of this command Is + xxxx yyyy zzzz where the 
user types xxxx and yyyy and the debug program computes zzzz 
as xxxx+yyyy. 
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- - Subtract numbers 

The form of this command is - xxxx yyyy zzzz where the 
user types xxxx and yyyy and the debug program computes zzzz 
as yyyy-xxxx. 

? - Display a menu 

This displays the menu of all available debug commands, 
showing the characters required and an English description 
of the commands. 


16.4.2 Establishing the Debug Environment. 

The system debugger can be added to the disk image of a DNOS 
system by executing the DEBUG command, located in the 
. S $ SYSTEM. S $$ CMDS command library. Before executing the DEBUG 
command, the following preparations should be made: 

1. Verify that the DEBUG procedure is in .S$SHARED as 
procedure ID 1 . 

2. Make the two root segments on the image program file 
updateable. This can be done by issuing the XSCU and 
QSCU commands. Issue the XSCU command with the 
following responses. 

[] XSCU 

EXECUTE SYSTEM CONFIGURATION UTILITY 

SYSTEM VOLUME: <volume name> 

SYSTEM NAME: <system name> 


where : 

An LDC listing appears. Press the Command key. 

Now issue the QSCU command with the following response 
[] QSCU 

QUIT CONFIGURATION UTILITY SESSION 

ABORT? : NO 
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3. Determine the Illegal XOP WP and PC values by issuing 
the LSM command with these responses : 

[ ] LSM 

LIST SYSTEM MEMORY 

OVERLAY NAME OR ID: ROOT 
STARTING ADDRESS: >50 
NUMBER OF BYTES: 040 
LISTING ACCESS NAME: 

Record the first two values starting at address 0050 
(for example, 2CA8, C56A)* These are the Illegal XOP 
WP and PC values, respectively. 

4. Now you are ready to Install the debugger. Enter .USE 

to give access to the DEBUG command ([ ] .USE 

S$SYSTEM.S$$CMDS, .S$CMDS). 

5. Then enter the DEBUG command: 

[] DEBUG 

ADD/REMOVE SYSTEM DEBUGGER 


ADD/REMOVE/MODIFY? : alphanumeric 

TARGET DISK/VOLUME: device name® (*) 

SYSTEM NAME: alphanumeric (*) 

XOP LEVEL ( 0 - 14 ): Integer (1) 

DEBUG TERMINAL CRU: integer (>100) 

DEBUG TERMINAL TYPE: { 9 1 1 , KSR , A SR , VDT , E I A , TTY } (911) 

ILLEGAL XOP WP: Integer (>2C48) 

ILLEGAL XOP PC: Integer (>C56A) 


Use the debug command to add or remove the system 
debugger from the disk image of a DNOS system, which is 
located in program file <target dl sk/volume>. <sys tem 
name>. The command may also be used to modify the 
operating characteristics (for example, debug terminal 
CRU address) of a previously Installed system debugger. 

PROMPT DETAILS: 

ADD/ REMOVE/ MODIFY? 

Enter ADD to add the debugger to a system. Enter 
REMOVE to delete the debugger from a system. 
Enter MODIFY to change the operating 
characteristics of a previously added debugger. 
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TARGET DISK/VOLUME 

Enter the name of- the disk volume containing the 
system to be debugged. 

SYSTEM NAME 

Enter the name of the system to be changed. The 
system kernel image file resides on a program file 
with the name <TARGET DI SK/ VOLUME> . < SYS TEM NAME>. 

XOP LEVEL [0 - 14] 

Enter the XOP level to be used by the debugger as 
a breakpoint instruction. The default is 1, but 
if the XOP level 1 is already in use, another 
level between 0 and 14 may be selected. 

DEBUG TERMINAL CRU 

The system debugger uses direct CRU I/O to 
terminal. Enter the CRU address of the terminal 
where you want debugger output to go. 

DEBUG TERMINAL TYPE 

Enter the type of terminal the debugger will write 
to. Choices are 911, VDT, TTY, EIA, ASR, KSR. 
The ASR or KSR must be connected through an EIA 
Interface module. 

ILLEGAL XOP WP 

Enter the WP value recorded from the earlier LSM. 
ILLEGAL XOP PC 

Enter the PC value recorded frotn the earlier LSM. 
Me s sage s : 

The DEBUG command will produce a listing in the 
terminal local file which sliows the XOP 
instruction to use for a breakpoint, the CRU 
address, and the terminal type. 

Notes : 

If the XOP level default is not selected, the 
normal breakpoint instruction (>2C40) set by the B 
instruction, will change. 

6. Note the third word of the display returned by the 
DEBUG command. This is the value which will be used as 
the breakpoint Instruction. It should be equivalent to 
the assembly language instruction 

XOP R0,<xop level> 

where <xop level> is the number you entered for the 
fourth prompt of the DEBUG command. Using listings and 
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linkmaps, choose the address of the task (DSR, SVC 
processor, etc.) where you wish to set your Initial 
breakpoint. Use the MPI (or MRF) command to modify the 
executable code Image at that address to contain the 
value noted above. Remember the proper value so that 
the Instruction can be be restored when you are 
debugging. 

7. Reboot the system or execute the task or whatever It 
takes to cause entry to the code of Interest at the 
selected address. Use the M debug command to restore 
the code at the Initial breakpoint address, then set up 
the debug environment that you require. Use the X or Z 
debug command to proceed with the execution of the code 
to be debugged. 


16.5 THE PICT UTILITY 

The PICT utility Is used In the DNOS source library to create 
tables from the assembly language templates to be used by Pascal 
code and to generate documentation pictures of the assembly 
Input, generating Pascal record descriptions and/or line drawing 
picture files. PICT Is controlled by the use of macros (verbs) 
In the assembly language Input files. These macros expand to 
appropriate assembly language code when used with the macros 
defined In the DNOS file . S $OSLINK. MACROS . TEMPLATE directory. 

The PICT utility can be accessed by using the PICT command In the 
. S$SYSTEM. S$$CMDS directory. The command has the following 
prompts, with descriptions as outlined below. 

PICT (CREATE DATA TABLE PICTURE) 

SOURCE FILE(S): filename 
PICTURE FILE: [filename] 

PASCAL OUTPUT FILE: [filename] 

PAGE CONTROL?: (YES,NO,Y,N) (YES) 


I Prompt Details: 

SOURCE FILE(S) 

Specify the file or files you want to have examined by the 
picture processor. If more than one file Is specified, the 
files are concatenated and processed as a single file. 

PICTURE FILE 

Specify the pathname for the picture file to be created 
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PASCAL OUTPUT FILE 

Specify the pathname for the file of equivalent Pascal 
statements • 

PAGE CONTROL? 

Specify NO If you want no embedded carriage control In the 
picture file that Is being built. Specify YES If you want 
carriage control. If you specify YES, the picture file will 
have a notation of (CONTINUED) after every 55 lines. 

The complete set of verbs available with PICT Is shown In Table 
16-6 along with the Intended purpose of each verb. 

The verbs are shown with brackets [] to Indicate optional 
arguments and braces {} to Indicate that a choice must be made 
from the Indicated options. 

■ f 

Since the assembly language macros automatically generate the 
label xyzSIZ for the structure named xyz, users must avoid using 
their own labels of the same format. 

The verbs are used In appropriate groupings to define various 
types of structures. The major structures are framed by DORG and 
RORG, CSEG and CEND, and PCKREC and ENDREC. The first pair of 
verbs Is used to to define an assembly language DSEG and a 
corresponding Pascal packed record variable declaration. The 
second Is used to define an assembly language CSEG (with data to 
be Initialized In an assembly language routine) and a 
corresponding Pascal packed record variable declaration. The 
third pair of framing verbs provide an assembly language DSEG and 
a Pascal packed record type declaration. The first and second 
set of framing verbs are Intended to be close to the work done In 
assembly language, while the third set provides easy definition 
of Pascal packed record structures with variants. 
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Table 16-6 Verbs Used In Generating Structures 



VERB 



[label ] 

ADDR) 

0 


[ label ] 

ARRAY 

number of elements , 

[ comment ] 



{INT, LONG, POSINT, WORD} 
or a type defined with 

PCKREC 


BITS 

[label,] number of bits 

[ comment ] 

[ label ] 

BSS 

number of bytes 

[ comment ] 

[ label ] 

BYTE 

CEND 

0 

[ comment ] 

[label ] 

CHAR 

number of characters 

[ comment ] 


COPY 

f 1 1 ename 



CSEG 

'label' 


[ label ] 

DATA 

0 

[ comment ] 


DORG 

n or label 

[ comment ] 


ECHO 

ENDREC 


[ comment ] 

labe 1 

EQU 

n or label 

[ comment ] 

[label ] 

EVEN 


[ comment ] 


FLAG 

label 

[ comment ] 

[label ] 

FLAGS 

{8,16} 

[ comment ] 

[label] 

INT 

LIST 

0 

[ comment ] 

[ label ] 

LONG 

0 

[ comment ] 


PAGE 

PCKREC 

label 

[ comment ] 

[label ] 

POSINT 

0 

[ comment ] 

[label] 

PTR 

type 

[ comment ] 

[label ] 

REC 

type specified 
by PCKREC above 

[ comment ] 


RORG 

UNL 

VARNT 

n or label 

[ comment ] 

[ label ] 

WORD 

0 

[ comment ] 


The COPY verb Is used to bring In a file before the PICT utility 
processes the entire Input file. If the Input file refers to a 
user-defined type or constant, the appropriate file must be 
copied In to supply the definition. Any number of COPY verbs may 
be used, but they cannot be nested. That Is, a file may not copy 
In a file which uses the COPY verb. 

Most of the other verbs can be used independently of each other, 
and they can appear in any of the three framing verb pairs. An 
exception is the set of verbs used to define flags fields. The 
verbs FLAGS, FLAG, and BITS must be used in a relatively 
restricted fashion. The FLAGS verb must appear first, defining 
the number of flags being generated to be either 8 or 16. This 
can be followed by an appropriate number of FLAG and or BITS 
verbs to complete the field of 8 or 16. The entire field does 
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not need to be explicitly defined. PICT will generate a filler 
label and allocation in the Pascal structure, and the assembly 
language macros generate only the required equates for the flags 
defined. 

For many of the verbs, the operand field Is optional. However, 
If a comment Is used, the. operand field must be supplied to avoid 
parsing part of the comment as operand. 


16.5.1 Assembly Language Output. 

The following paragraphs describe the effect of each of the verbs 
for the assembly language output. The succeeding set of 

paragraphs describe the Pascal output, and a third set of 

paragraphs describe the picture output generated by PICT. 

[label] ADDR 0 

This generates a one word integer 
[label] ARRAY n,type 

This generates an optionally labeled field with a BSS for 

the appropriate number of bytes to allocate n instances of 

the type specified. 

BITS [label, ]n 

If a label Is specified, an EQU is generated with the label 
equated to the current autogenerated bit number within the 
FLAG field. 

[label] BSS 5 

This is a standard assembly language directive. 

[label] BYTE 0 

This is a standard assembly language directive. 

CEND 

This is a standard assembly language directive. 

[label] CHAR n 

This generates a BSS for the number of characters specified. 
COPY filename 

This is a standard assembly language directive. 

CSEG label 

This is a standard assembly language directive. 

[label] DATA 0 

This is a standard assembly language directive. 

DORG n or label 

This is a standard assembly language directive. 
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ECHO 

This Is Ignored. 


ENDREC 

This terminates a record definition begun with PCKREC. It 
generates a size equate aaaSIZ where aaa is the name of the 
packed record and an RORG 0 statement. 

label EQU n or label 

This is a standard assembly language directive. RESERVE 
BLOCK 3 


[label] EVEN 

This is a standard assembly language directive. 

FLAG label 

This generates an EQU, with the label equated to the current 
autogenerated bit position within the FLAGS field. The 
first flag position is always position 0. 

[label] FLAGS {8,16} 

If the operand is 8, this generates a BSS 1. IF the operand 
is 16, it generates a BSS 2. 


[label] INT 0 

This generates a BSS 2. 


LIST 

This is a standard assembly language directive. 


[label] LONG 0 

This generates a BSS 4. 


PAGE 

This is a standard assembly language directive. 


PCKREC name 

This begins a packed record, indicated by a DORG 0. Notice 
that if the packed record is to be assembled as well as used 
with PICT, the structure name is limited to a maximum of 
three characters. 


[label] POSINT 0 

This generates a BSS 2. 

[label] PTR type of pointer 
This generates a BSS 2. 


[label ] REC type 

This uses the aaaSIZ equate built during processing of a 
PCKREC to generate a BSS of the appropriate size. 
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RORG 

This Is a standard assembly language directive. 

UNL 

This Is a standard assembly language directive. 

VARNT n or label 

This generates a DORG n, where n Is the supplied value or 
the value of the label. 


[label] WORD 0 

This generates a BSS 2. 


16.5.2 Pascal Template Output, 

The following paragraphs describe the output generated by PICT 
for use In Pascal code. In cases where a label Is output to the 
Pascal file but no label Is supplied by the Input line, PICT 
generates a label of the form FILLxy where xy begins at 00 and Is 
Incremented by 1 with each new filler label used. 

In most cases, the comment found on an Input line which generates 

an output line Is also found on that output line. The exceptions 

are output lines of PACKED RECORD, CASE INTEGER OF, and variant 
labels. 

Each output file Is Intended to be unlisted In a Pascal program. 

The first line Is always (*$ NO LIST *) and the last line Is 

always (*$ RESUME LIST *). 

[label] ADDR 

This generates: label : ADDRESS; (ADDRESS Is defined In the 

DNOS file .TEMPLATE .PTABLE. TYPES as 0..y/FFFF) 

[label] ARRAY n,type 

This generates: label : PACKED ARRAY [l,.n] OF type; 

BITS [label, ]n 

This generates: label : 0..m; where m Is the maximum value 
which can be expressed In n bits. For example, BITS ALPHA, 3 
generates ALPHA : 0,.7; 

[label] BSS n 

This generates: label : PACKED ARRAY [l..n] OF BYTE; 

[label] BYTE 0 

This generates: label : BYTE; (BYTE Is defined In the DNOS 
file .TEMPLATE .PTABLE. TYPES as 0..#FF) 

CEND 

This generates: END; for a CSEG file. 
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[label] CHAR n 

This generates: label ; PACKED ARRAY[l..n] OF CHAR; 

COPY filename 

This causes no Pascal output. 

CSEG label 

This Is the beginning of a packed record named by the CSEG 
label. It generates: label = PACKED RECORD (where the 
label has no quotes, though the CSEG label does) 

[label] DATA 0 

This generates: label : WORD; (WORD Is defined In the DNOS 

file .TEMPLATE . PTABLE. TYPES as 0..//FFFF) 

DORG n or label 

Depending on where It appears In an Input file, this might 
be the start of a packed record or the beginning of a 
variant In the packed record. It is recommended that PCKREC 
be used when creating new structures and that DORG be used 
only for compatibility purposes. (DORG will also be needed 
if the structure must have a starting location counter value 
that Is non-zero.) 

When encountered the first time In a file, DORG 0 generates 
XXX = PACKED RECORD where xxx Is the first three characters 
In the next line with a label (unless that line has an EQU 
directive. In which case It Is skipped). When encountered 
In succeeding lines of the file, DORG generates a variant at 
the current level. Thus several DORG statements In 
succession with the same operand will generate variants at 
the same level. A new operand on a succeeding DORG defines 
a deeper level of nesting. It Is necessary, of course, to 
have all variants (and variants within variants) at the end 
of the structure being defined. (See the description of 
VARNT for further details.) 


ECHO 

The entire Input file is ignored and no Pascal output Is 
generated other than the NO LIST and RESUME LIST directives. 
The ECHO option is Intended for files of equates needed only 
for assembly language use. 

ENDREC 

This generates: END; for the packed record under 
cons t ruct Ion . 


label EQU n or label 

This generates no Pascal output. 

[label] EVEN 

This is Ignored . 
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[label] FLAGS {8,16} 

This begins a flags field, that is a packed record of 
boolean values. It generates: label : PACKED RECORD 

FLAG label 

This identified a flag and generates: label : BOOLEAN; 
[label] INT 0 

This generates: label : INTEGER; 


LIST 

This is Ignored. 

[label] LONG 0 

This generates: label : LONGINT; 


PAGE 

This is Ignored. 


PCKREC name 

This generates: name = PACKED RECORD 


[label] POSINT 0 

This generates: label : POSINT; (POSINT is defined in the 

DNOS file .TEMPLATE. PTABLE. TYPES as 0..#7FFF) 


[label] PTR type of pointer 

This generates: label : (§type; 


[label] REG type 

This generates: label : type; 


RORG 

This is used to terminate a packed record started by DORG 0. 
It generates END; 


UNL 

This is Ignored. 
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VARNT n or label 

This begins a variant of the current packed record at the 
current level If the operand Is the same as the start of the 
current level. If the operand Is not the same, a next level 
of variant Is begun. This requires that variants be defined 
In correct order of nesting. That Is, variants of a 
structure (or of variants) appear at the end of the 
structure. At the first VARNT of a given level, the 
following Is generated: 

CASE INTEGER OF 

1 : ( 

Succeeding variants at the same level generate succeeding 
Integer labels and open parentheses for the case statement. 
Variants of variants generate a CASE statement and the label 
1: ( for the first such variant and succeeding Integer 

labels and open parentheses for the following variants. The 
termination of the structure (ENDREC, RORG , or CEND) cause 
the output of all required matching parentheses to close the 
CASE(s) currently open. 

[label] WORD 0 

This generates; label : WORD; (WORD Is defined In the DNOS 
file .TEMPLATE. PTABLE. TYPES as 0..//FFFF) 

16.5.3 PICT Picture Output. 

The following paragraphs describe the output generated by PICT In 
Its picture output file. Consult Figure 16-3 for an example of 
some of the output generated. Any structure that must output 
more than four words of unlabeled blocks outputs a broken picture 
but maintains an accurate location counter value. Fields that 
must start on word boundaries do so, with the picture showing an 
unlabeled byte preceding that word boundary. 

Each line of the picture carries the associated comment of the 
Input line, as well as portraying the space occupied by the verb 
In use on that line. Some Input lines do not affect the picture 
but are used for Information which appears after that picture. 
Flag details, equate Information, and special comments follow the 
picture. A PAGE verb must appear at the end of the Input file to 
cause output of flag details, equate Information, and special 
comments . 

[label] ADDR 

This outputs a labeled block of one word on a word boundary, 
[label] ARRAY n,type 

This generates a labeled block of one byte (If the array 
occupies only one byte or begins on an odd byte boundary) or 
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a labeled block of one word, followed by unlabeled blocks 
filling out the structure. 


BITS [label , ]n 

This generates an entry in the equates listing at the end of 
the picture file, specifying the label and its location in 
the structure . 

[label] BSS n 

This generates a labeled block of one byte in the diagram 
and an appropriate number of unlabeled blocks. 

[label] BYTE 0 

This generates a labeled block of one byte. 


CEND 

This is Ignored. 


[label] CHAR n 

This generates a labeled block of one byte and an 
appropriate number of unlabeled blocks. 


COPY filename 

This is Ignored. 

CSEG label 

This is assumed to occur only at the start of the picture. 
Thus all Initial conditions hold -- the location counter is 
zero, no output is generated. 

[label] DATA 0 

This generates a labeled block of one word on a word 

boundary. 

DORG n or label 

This sets the location counter to the operand value, 

terminates any picture in progress, outputs the comment on 
the DORG line, and sets conditions to start another picture 

segment (indicated by * 1 *). 


ECHO 

This causes the entire input file to be written to the 
picture file as it is read. It is assumed to be a file 
which otherwise generates no meaningful picture. 

ENDREC 

This finishes a picture section, drawing a line below any 
partially completed block and outputting the size of the 
packed record just completed. It also outputs the message 
**END OF PACKED RECORD. 

label EQU n or label 

This generates a line of output in the listing of equates 
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which follows the picture. 

[label] EVEN 

If the picture is currently not at a word boundary, an 
unlabeled block of one byte is output. 

[label] FLAGS {8,16} 

A labeled block of one byte is output if the operand is 8; a 
block of one word on a word boundary is output if the 
operand Is 16. 

FLAG label 

This generates an entry in the flags descriptions which 
follow the picture. Each flag is shown with its relative 
position in the field as well as any comment describing that 
flag. Comments on lines following the FLAG input line are 
also echoed in the flags description in the picture output 
f lie . 

[label] INT 0 

This generates a labeled block of one word on a word 
boundary . 


LIST 

This is Ignored. 


[label] LONG 0 

This generates two words, with the first word carrying the 
label and appearing on a word boundary. 


PAGE 

This is used to determine that the end of the structure has 
been reached. It causes flags and equate descriptions to be 
output. Any comment lines which follow the PAGE line will 
be output at the end of the picture listing under the 
heading COMMENTS ON THIS STRUCTURE. This verb is REQUIRED 
in order to output flags and equates information to the 
picture file. 

PCKREC name 

This begins a picture section, with the location counter set 
to zero. It outputs a line with **BEGINNING PACKED RECORD 
name . 

[label] POSINT 0 

This outputs a labeled block of one word on a word boundary, 
[label] PTR type of pointer 

This outputs a labeled block of one word on a word boundary, 
[label] REG type 

This outputs a labeled word on a word boundary and an 
appropriate number of unlabeled blocks to encompass the 
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total required by the type specified, 

RORG 

This is Ignored. 


UNL 

This is Ignored. 


VARNT n or label 

This finishes the current picture section, sets the location 
counter to the operand specified, and initiates a new 
section. It outputs any comment on the VARNT input line, 

[label] WORD 0 

This outputs a labeled block of one word on a word boundary. 


16.5.4 Input Format. 

The input file may be in one of several forms, one of which is 
shown in Figure 16-1 and another which is shown in Figure 16-2. 
The name of the structure is shown as aaa . The heading comments 
are of the form used for DNOS structures and are not enforced by 
the PICT utility. Any comments that precede the first structure 
verb appear in the output files before the structure. Comments 
to be printed at the end of the picture file must appear after a 
PAGE statement. 

Figure 16-3 shows the format of the picture drawn by PICT, Each 
line of the drawing is preceded by the hexadecimal offset into 
the template. Each field carries its own label. 


2270512-9701 


16-33 


DNOS Tools 



DNOS System Design Document 


UNL 

************************************************************ 
* * 

* <full structure name> (<aaa>) <date>* 

* * 

* LOCATION: <locatlon In system> * 

************************************************************ 

<any comments to appear before the structure> 

<any COPY statements needed by statements In this flle> 
PCKREC name 

<label> <verb> <value> descriptive comment 


<label> <verb> <value> descriptive comment 

ENDREC 

<more packed records might be defined here> 

PAGE 

LIST 


Figure 16-1 PCKREC Input Format 


UNL 

************************************************************ 
* * 

* <structure name> 

* 


(<aaa>) 


<da t e >* 
* 

* LOCATION: <locatlon In system> * 

************************************************************ 

<any comments to appear before the structure> 

DORG <value> or CSEG 'label' 

<label> <verb> <value> descriptive comment 


<label> <verb> <value> descriptive comment 

aaaSIZ EQU $ 

RORG or CEND 

PAGE 

LIST 


Figure 16-2 DORG Input Format 
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<all comments which preceded the first structure verb> 




>00 

j 

<label> ! <label> 

1 

<comme nt > 



+ — 


+ 



>02 

I 

<label> 

1 

<comment > 



+ — 

+ 

+ 





<et c> 





+ — 

+ 

+ 



>mn 

1 

<label> 

I 




* — 

+ 

* 



FLAGS 

FOR 

FIELD: <fleldname> 

#mm - <label> 



<flagname> = (x 

• 

.... ....) — 

<comment > 






<special comments> 






<et c> 


<flagname> = (..x. ... 

• 

.... ....) — 

<comment > 


<e t c> 

<repeated for each flag field> 

EQUATES : 

FIELD OFFSET EQUATE VALUE DESCRIPTION 


<label> #nn <label> #mm <comment> 

<et c> 

Figure 16-3 Template Picture Format 


16.6 THE JENDAT EDITOR 

The JENDAT editor is used to edit the JENDAT file used by DNOS 
system generation. It Includes commands to show the current 
content of the JENDAT file, to edit any field, to format a file 
for printing, to remove records from the file, to change the 
version number of the file, and to exit the JENDAT editor. 


16.7 XJENED Command Procedure 

The DNOS JENDAT editor is Invoked from SCI through the XJENED 
command procedure. No prompts are Included. The program expects 
to find a value for synonym JENDAT, which specifies the file that 
the editor edits. The normal value of the synonym is 
. S $ SGU . JENDAT . If the synonym is not defined, a file named 
.JENDAT@$ST is created (where $ST is a synonym for the users 
station ID). This file is empty and does not produce the desired 
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results. This error is easy to detect. A SHOW or REMOVE command 
responds with NUMBER OUT OF RANGE in the error field. The EDIT 
command responds with NEW RECORD to any entry in the record 
number field. Quit the edit and assign the proper value to 
synonym JENDAT. 

The program also expects a value for synonym PFILE, which 
specifies the file used for producing a formatted copy of the 
JENDAT file. This data goes to .PFILE@$ST otherwise. This file 
should be precreated with a logical record length of 132. If the 
file has a logical record length less than 132, the file will 
have twice the normal number of records. For example, the first 
line becomes two lines, the first containing the numeric data 
from the JENDAT record, the second containing the text portion. 
The file contains escape sequences that compress the print of the 
810 printer and then restore it for normal operation at the end 
of the file. The file should be printed with 82 lines per page. 


NOTE 

The DNOS JENDAT editor requires a 911 VDT . 
Otherwise, it will not function properly. 


16.8 JENED Commands 

The commands available for the maintenance of the DNOS JENDAT 
file are as follows: 


COMMAND MEANING 


EDIT 

PRINT 

QUIT 

REMOVE 

SHOW 

VERSION 

MOVE 


Edit any field of a record) 

Format a file for printing) 

Exit the JENED editor) 

Remove records from the JENDAT file) 

Show the text of the JENDAT records) 

Change the version number of the JENDAT file 
Relink records of the file 


The JENED program begins with a display of the main menu, which 
lists the commands available to the user. The main menu is as 
follows : 
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SELECT ONE OF THE FOLLOWING ; 

P - PRODUCE A FILE FOR PRINTING 
V - CHANGE VERSION NUMBER OF JENDAT 
R - ZERO FIELDS OF JENDAT RECORDS 
S - SHOW TEXT OF JENDAT RECORDS 
E - EDIT FIELDS OF JENDAT RECORDS 
M - RELINK JENDAT RECORDS 
Q - QUIT 

COMMAND ; _ 

The character entered does not terminate the call. To process 
the command, the user must hit RETURN. Invalid entries are 
ignored . 

16.8.1 EDIT Command. 

When the EDIT command is entered, the menu field is replaced by 
the editing template. The following is an editing template: 

EDIT RECORD NUMBER 


1 2 3 4 5 6 

DEF AAT LB UB NEXT 


The number entered is a decimal number. A zero entry or empty 
entry places the editor in the append mode. As a result, the 
first field indicates that a new record is being entered. The 
first field is modified as follows; 

EDIT RECORD NUMBER NEW RECORD 


The text field is initialized with blanks. The first four 
numeric fields are initialized with 0000, and the NEXT field is 
Initialized to the record number of the record following the 
current record. 

If an error is detected in the field, the following error message 
is dl splayed : 

EDIT RECORD NUMBER 12AE 

ERROR IN NUMERIC FIELD 


If the record number is larger than that of the last record of 
the current file, the editor enters the Insert mode. The record 
displayed is one larger than the last record, and the message NEW 
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RECORD Is displayed. If the record number exists, the 

corresponding data appears on the screen. The cursor is 
positioned in the first column of the text field when a valid 
record number has been chosen. 

The JENDAT editor requires a call termination character for each 
read that is issued. The valid termination characters, which 
vary with the call that is outstanding, are as follows: 

* CMD 

* RETURN (SKIP) 

* ENTER 

* Up Arrow 

* Down Arrow 

* FI (function key 1) 

* F7 (function key 7) 

* F8 (function key 8) 

* TAB 

* Left Field 
CMD Key 

The CMD always returns the user to the main menu from the 
edit mode, whether editing existing records or inserting new 
records. The current record is never updated with the data 
on the screen. 

RETURN Key 

The RETURN key causes the call to progress from the text 
field to the DEF field, then to AAT , LB, UB , and NEXT, in 
that order. When the RETURN key is entered from the NEXT 
field, the data on the screen is moved to the file. The 
next physical record is entered on the display, and a read 
is issued to the text field. The record number field is 
updated to the record number of the data that is displayed. 
The SKIP key causes the same effect as RETURN but blanks out 
the remainder of the field. This produces acceptable 
results in the record number field and the text field but 
should be avoided in the numeric fields. 
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NOTE 

The JENDAT file Is not a forced write file. 
Therefore, the data Is moved to the memory 
buffer that will be written by file 
management when necessary to free buffer 
space • 


ENTER Key 

The ENTER key causes the data on the screen to be written to 
the file. The next physical record Is entered Into the 
display, and a read Is Issued for the text portion of the 
record. 

Down Arrow Key 

The Down Arrow key causes the next physical record to be 
displayed. The file Is not altered In any manner. 

FI Key 

Function key FI causes the next logical record to be 
displayed (that Is, the record whose record number Is, 
currently displayed In the NEXT field). No data Is written 
to the file by this key. 

F7 Key 

Function key F7 causes . the editor to enter the find mode 
when entered In any field of the record. The message FIND 
MODE Is displayed, and the record displayed Is empty. 
Altering any field causes all records of the JENDAT file to 
be searched for a record that matches In all of the chosen 
fields. If no match Is found, the editor returns, 
displaying the NEW RECORD message at the end of the file. 
This Indicates that the search failed. If the record Is 
found, the editor returns to the edit mode, displaying the 
record that It found. 

The text field Is searched only when nonblank characters are 
entered In the text field when the FIND MODE message Is 
displayed. A numeric field Is searched when the field Is the 
search. Entering any other valid termination characters returns 
the editor to edit mode at the displayed record number. 

F8 Key 

The F8 key returns to the record number field. This permits 
the user to jump from editing record number 15 to record 
number 65 by entering F8, followed by 65, and RETURN (SKIP). 

TAB Key 

The TAB key Is acceptable only In the text field. Tab 
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settings are fixed at 1, 8, 13, 31 and 76. Entering TAB 
causes the read to be reissued at the next tab setting. The 
fields rotate; that Is, a TAB key entered at column 76 
returns to column 1. TAB Is not accepted In the numeric 
fields. 

Left FIELD Key 

The Left FIELD key acts as a reverse tab In the text field. 
A Left FIELD Issued from column 1 Is Ignored and returns to 
column 76. In the numeric fields, pressing Left Field 
causes a return to the previous field. Including a return to 
the text field from the DEF field. 

If an error Is detected In a numeric field, the message ERROR IN 
NUMERIC FIELD Is displayed. When the error Is corrected, the 
message disappears. Entering CMD corrects the error condition 
but also returns the user to the main menu.* Some errors will not 
be detected. The RIFLE DECODE procedure terminates the scan when 
It finds letters while decoding a hexadecimal field. Thus, 
entering OIWQ In a hexadecimal field places 01 In that field. 


16.8.2 PRINT Command. 

Entering the PRINT command produces a file for printing. The 
display Is Informative only, displaying the record number of the 
file currently being processed. 


16.8.3 QUIT Command. 

Eaterlng QUIT closes the JENDAT file and updates record 0 to 
reflect the current version number and number of records In the 
file. 


16. 8. A REMOVE Command. 

Entering REMOVE displays the following message: 
REMOVE RECORDS 

FROM TO 

ARE YOU SURE? 


The numbers entered are validated and may produce either the 
NUMBER OUT OF RANGE message or the ERROR IN NUMERIC FIELD 
message. If the response to ARE YOU SURE? Is Y, the records 
from the first number to the second are deleted. This removes 
the text and enters zero In each numeric field except NEXT, which 
has the next physical record. To return to the first field from 
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the second, enter the Left FIELD key. This requires that a 
number for the second field be entered. If the fill character 
(_) fills the field, the Left FIELD key Is not accepted. 


16.8.5 SHOW Command. 

The SHOW command produces the following prompt: 
SHOW TEXT FROM RECORD 


The field is validated; and If It Is correct, the text of the 
records beginning with that record and extending through the next 
22 records Is displayed. If less than 22 records follow the 
number entered, only those records that exist are displayed. 

This command accepts the up arrow, down arrow, FI, and F2 keys In 
the same fashion as SHOW FILE. F6 Is a toggle switch that rolls 
the file horizontally. 


16.8.6 VERSION Command. 

The VERSION command produces the following prompt : 
VERSION NUMBER 01 


The number shown Is the version number checked by SYSJEN to 
verify compatibility. The number entered replaces the current 
one. No error checking Is done. 


16.8.7 MOVE Command. 

The MOVE command produces the following prompt: 

MOVE A RECORD 

INSERT RECORD BETWEEN AND 


This command causes the first record to be logically inserted 
between the second and third records. All records which 
originally pointed to the first record, now point to the logical 
successor of the first record. 
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SECTION 17 

ANALYZING A SYSTEM CRASH 


17.1 OVERVIEW 

When DNOS detects a system failure, It displays an error code In 
the lights of the front panel and Idles the CPU. To analyze the 
problem, copy the memory Image to the predefined crash file 
.S$CRASH on the system disk by pressing HALT and then RUN on the 
programmer panel. When activity ceases, and the error code Is 
redisplayed, perform an Initial program load by pressing HALT, 
and LOAD* When DNOS Is ready, log on to a terminal and study the 
crash file using the crash analysis utility. 

The crash analysis utility can be used to study a crash file or a 
running system. The paragraphs that follow discuss the commands 
available with the crash analysis utility and tell when each 
command Is useful* In addition, guidelines are presented for 
analyzing several particular system crash conditions. 

The crash analysis utility Is Invoked with the XANAL command to 
SCI. The XANAL command procedure Is of the following format: 

XANAL 

EXECUTE CRASH ANALYSIS UTILITY 

CONTROL ACCESS NAME: pathname® (ME) 

LISTING ACCESS NAME: pathname® (ME) 

ANALYZE RUNNING SYSTEM: YES/NO (NO) 

CRASH FILE NAME: pathname® (.S$CRASH) 

The prompts and responses are described In detail below. 

CONTROL ACCESS NAME 

This field prompt asks for the access name of the file or 
device that will be used to Issue commands to the utility. 
Most often, the Initial value Is accepted, and commands are 
Input from the station at which the XANAL command was 
Issued. In certain cases, you may want to use a standard 
set of analysis commands from a file. If so, each command 
must start In column 1 of a separate record of the file. 

LISTING ACCESS NAME 

If the crash analysis Is to be written to a file, specify a 
file name. If the station Is to receive the listing, accept 
the initial value. 
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ANALYZE RUNNING SYSTEM 

Accept the initial value of NO If you wish to examine a 
crash file on disk. Enter a YES to analyze portions of the 
running system. 

CRASH FILE NAME 

When examining a running system, accept the initial value 
for this prompt. When analyzing a crash dump, specify the 
name of the file. Each time a system crash dump occurs, the 
information is written to the file .S$CRASH on the system 
disk. To protect a crash file from being overwritten, copy 
it to a new file using the CD (Copy Directory) command. 
Specify .S$CRASH as the input pathname and the desired 
directory as the output pathname. Upon completion, the 
crash file will be found as S$CRASH within the directory 
specified • 

When the crash analysis utility is used interactively, the 
listing comes to the screen at a rapid pace. To stop the 
display, press the Attention key; to resume the display, press 
the Attention key again. To exit a command display, press the 
Command key. 

The ANALZ task is an RBID task, therefore you can enter and exit 
the analysis of a crash to use SCI. Table 17-1 shows the set of 
commands used with ANALZ to examine a running system or a crash 
file. The commands are described in detail in the paragraphs 
which follow. 
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Table 17-1 Crash Analysis Commands 
Command Display Contents 


ALL 
AQ 
CCB 
DM 
FCB 
GI 
JSB 
LDT 
MM 
OVB 
PBM 
PDT 
PQ 
QU 
ROB 
RPB 
SGB 
SSB 
ST 
TA 
TR 
TS 
TSB 
? ? 


Displays from all the commands 

Contents of task active queue 

Channel control blocks 

Specific area of memory 

File control blocks 

General information 

Job status blocks 

Logical device tables 

Memory maps 

Overhead beets 

Partial bit maps 

Physical device tables 

System queues (other than active qu^ue) 

No display; terminates session 

Resource ownership blocks 

Resource privilege blocks 

Segment group blocks 

Segment status blocks 

Secondary table areas 

Task areas in memory 

Registers for all tasks 

Task status 

Task status blocks 

List of all available commands 


17.2 DETAILS OF CRASH ANALYSIS COMMANDS 

When analyzing; a crash, the initial step should be to examine the 
general information about the crash, followed by an examination 
of task states and then of the detailed information about 
particular queues and data stuctures. First issue a GI command, 
then a TS command , and then the relevant structure examination 
command. All of the commands and their parameters are presented 
in alphabetic order In the following paragraphs. 

ALL 

This command lists the information for all the commands 
available. It is frequently used to process a crash file to 
a listing file which can then be sent to someone for 
inspection. When the ALL command is processed, it generates 
output for the commands in this order: GI , TS , JSB, TSB, 
SGB, SSB, PDT, FCB, LDT, ROB, CCB, MM, OVB, AQ , PQ , ST, TR, 
and TA. 
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This command causes the display of three lists, the list of 
tasks on the active queue, the list of tasks waiting for 
system table area, and the list of tasks on the waiting on 
memory queue. Each list shows the JSB address, priority, 
TSB address, and IDs for the tasks Involved. 

If the queues are empty, the system was idle. If the queues 
have many entries, the system was busy. Scanning the 
queues, you can see what tasks were eligible to execute or 
be loaded Into memory. This Information Is helpful when 
forcing a crash during a situation where the system appears 
to be Idle or hung In a loop. 


CCB 

This command shows the channel control blocks for all 
channels currently In use. It first shows the global 
channel list from the system table area then the job local 
list from the JCA of each job In the system. Each job local 
list is Identified by its JSB address. 


Before displaying memory, this command solicits data for the 
following : 

LOWER LIMIT - the starting address (rounded to even number) 
UPPER LIMIT - the ending address 

JSB ADDRESS - a JSB address, an SSB address for any SSB, or 
TSB ADDRESS -• the TSB address for the task memory being 
displayed 

or PDT ADDRESS - the PDT address of a device being viewed 
or BEET BIAS - for any beet In memory 

If the answer to the JSB ADDRESS prompt Is 0, the PDT 
ADDRESS prompt appears. If the answer to the PDT ADDRESS 
prompt Is 0, the BEET BIAS prompt appears. 

The first time DM Is used, the prompt for LOWER LIMIT Is 0. 
After the first time, the prompt has an initial value of the 
previously used LOWER LIMIT. The UPPER LIMIT Is Initialized 
with a value >2E greater than the LOWER LIMIT value. The 
default listing Is a three~llne display of >30 bytes of 
data, each line preceded by the address of the first word on 
that line. The data Is shown In hexadecimal and in ASCII 
equivalent. Initial values for JSB ADDRESS and TSB ADDRESS 
are the values used previously, after the first DM has been 
specified. 

To examine a physical TILINE address, specify the address as 
LOWER LIMIT, and specify zero for all other fields of the DM 
command . 
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FCB 

This command causes a display of all In-memory file 
structures for files currently in use. It presents the set 
of structures for each disk device defined for the system, 
showing for each file the FDB, FCB, and SAT. 


General Information about a crash Is shown by this command. 
Including all of the following for analysis of a crash file. 
For analysis of a running system, the information beginning 
with SYSTEM PATCH AREA is presented. 

VERSION 

The re lease / ve r s ion/ re vl s ion level of the system or crash 
file being analyzed is shown here. This field provides 
verification of the current level of software in use. 

CRASH CODE 

The code is shown as a four-digit hexadecimal value. If the 
crash code is one of those Included in internal tables, an 
English description of the code is also output. Details on 
system crash codes are provided in the DNOS Messages and 
Codes Reference Manual. 


EXECUTING TASK 

The next item displayed is the TSB address of the executing 
task at the time of the crash. If the TSB address is shown 
as 0, there was no executing task at the time of crash. The 
error was probably within the operating system during a 
scheduling cycle. 

If the crash was an end action crash, this field identifies 
the task which took end action. If the crash was forced, 
this field identifies the task which was in a loop when the 
crash occurred. The information here may not be useful for 
crashes in the range >13 through >1F (illegal Interrupts) or 
for the >60 series crashes (operating system failures). 

EXECUTING TASK JSB 

This displays the address of the JSB of the task executing 
when the crash occurred. Paired with the EXECUTING TASK 
data, it identifies the task executing at the time of the 
crash . 

LOCATION OF FAILURE 

This is the address from which the crash routine NFCRSH was 
called or, in some cases, the location of an Illegal 
instruction or other cause of the crash. 

For crashes in the >60 series, this is not useful. For a 
>29 crash (unexpected error return), this field identifies 
whether NFPOPO or NFRTNO encountered the error. 


2270512-9701 


17-5 


Analyzing a System Crash 



DNOS System Design Document 


STATUS REGISTER AT TIME OF FAILURE 
This shows the contents of the status register when the 
crash occurred. Bit 8 Indicates whether the error occurred 
while executing in map file 0 (bit 8=0) or In map file 1 
(bit 8=1). The last four bits show the interrupt mask. If 
the Interrupt mask is less than <15, the error probably 
occurred in a DSR or in the clock Interrupt handler. This 
display is not useful for >60 series crashes. 

JCASTR 

This is the starting address of all JCAs and other table 
area second segments mapped in by DNOS. 

COUNTRY CODE 

This entry shows the country code of the system. 

IMAGE NAME 

The name of the kernel program file that was executing is 
shown . 

MEMORY SIZE 

This shows the total memory available to the system while 
operating. This value is less than or equal to the total 
physical memory available. 

CRASH FILE SIZE 

This shows the size of the crash file in use. If this is 
not as large as MEMORY SIZE, some portions of the crash dump 
will be missing, and the following message will appear at 
the start of the GI display: 

*** WARNING *** ALL MEMORY NOT IN DUMP FILE 


This generally means the dump is not useful. You should 
Increase the size of your crash file. 

CURMAP ADDRESS 

This entry shows the address of the current map 0 map file 
at the time of the crash. Bias values might be used to 
examine portions of memory. This field is not generally 
useful if the crash occurred in map file 1, 

SYSTEM PATCH AREA 

This shows the system patch area in hexadecimal and the 
ASCII equivalent. The area might be scanned to ensure that 
all appropriate patches have been applied to the system. 
The starting address of the patch area should be the same as 
the symbol NFPATCH in the system link map. 
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EXECUTING WORKSPACE AT TIME OF DUMP 
These registers are the workspace registers of the executing 
code at the time of the crash. If the crash occurred in map 
file 0, this area shows the true contents of the registers 

at the time of the crash. If the crash Is for a task taking 

end action, these registers are those of Its end action 
workspace, which may or may not be those In effect at the 
time the error occurred. 

TOP 64 WORDS OF CURRENT STACK 

This display assume s that register 10 of the executing 
workspace is a stack pointer. The utility displays 32 words 

preceding the address In register 10 and 32 words following 

the address in register 10. 

This data is most useful if the crash occurred In map file 
0, or in a system task. 

If the executing code does not use the stack, this area may 
be useless. Unused memory appears as initialized to >F00D 
values. 

HARDWARE TRAP VECTORS 

The hardware Interrupt vectors occupy the first 32 words of 
physical memory and are defined during system generation. 
These vectors should not be changed unless destroyed by a 
system task that branches to location 0 by mistake or 
modifies location 0 when using an Incorrectly established 
address field. If a BLWP Instruction Is executed to 
location 0, the return context Information of the calling 
task is stored In locations >1A through >1F. 

When the crash code Is for an illegal interrupt (>13 through 
>1F), these vectors are meaningful and should be examined 
carefully. When a crash code for Internal interrupt (>60 
through >6F) occurs and the Interrupt mask In register 15 of 
the trap 2 workspace indicates a defined interrupt (mask 
value minus one), the Interrupt trap values should be 
checked to determine If they are within range. The correct 
values can be determined by examining locations 0 through 
>3F of procedure ROOT In the kernel program file. 

XOP VECTORS 

The XOP vectors occupy the second 32 words of physical 
memory and are defined during system generation. These 
vectors should not be changed unless destroyed by a system 
task In error. Their correct values can be found in the 
same way as the HARDWARE TRAP VECTORS values. 
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CLOCK INTERRUPT WORKSPACE 

This area shows one of the two clock workspaces. This 

display workspace shows the current state of the clock 
interrupt processor. Registers 13 through 15 show the 
return context of the last entry to the clock Interrupt 
processor. When a crash is forced during a system hang 

condition, this workspace may point to the location of an 

infinite loop in a task, that is, the location at which the 
last clock Interrupt occurred. 

MACHINE ERROR (TRAP 2) WORKSPACE 
This workspace contains diagnostic information about a crash 
for Internal Interrupts (>60 through >6F) . The context of 
the crash can be found in registers 13 through 15. If bit 8 
of register 15 is set to 1, the error occurred in task 

driven code (map file 1). If bit 8 is set to 0, the error 

occurred in system code (map file 0). Register 1 of this 

workspace carries a status code, reflected as the second 
digit of the >60 series crash. A >62 crash can be 
recognized as a forced crash if R14 points to an instruction 
whose preceding instruction is a zero. If R14 has a value 

less than that of JCASTR, the error occurred in the root. 

Otherwise, if in map file 0, check the CURMAP address of the 
GI information against a system link map for the correct 
segment of code. If executing in map file 1, consult the 
appropriate task link map for the correct segment of code. 

TRAPPED WORKSPACE 

This workspace is found using R13 of the machine error 
workspace as the starting address. 

LOCATIONS AROUND TRAPPED PC 

This display shows the 16 bytes before and 16 bytes after 
the address found in R14 of the machine error workspace. 

SVC (XOP 15) WORKSPACE 

This workspace is used by both the scheduler and SVC 
processing. The workspace contains the current state for 
whichever of those processors last used it. Registers 13 
through 15 may contain the return context (workspace 
pointer, program counter, and status) from the last SVC 
Issued by a task. If the crash occurred in map file 0, this 
workspace is probably the executing workspace. If the 
workspace is not that of the scheduler, it may be a DSR 
workspace; if the starting address is in one of the PDTs , it 
reflects the workspace of a DSR. 


JSB 

This command displays the job status blocks for every job in 
the system. The last JSB presented is that for the system 
job . 
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LDT 

This command displays, with appropriate headers, all global 
LDTs , followed by all job-local LDTs identified by JSB 
address, and finally all task-local LDTs Identified by TSB 
and JSB addresses. 


Memory map information, specifying starting address, length, 
current use, highest address, and free block chain, is 
presented for each of the following: 

* System table area 

* Special table areas for segment management and for 
file management 

* Job communication areas for each job in the system 


Information is then presented on user memory available, both 
that available to be swapped and that not available to be 
swapped. This is followed by tables of linked lists for 
these structures: 

* Free list of user memory 

* Deallocate queue 

* Time ordered list 

* Cache queue 

* Write queue 

* Buffer table area free list 


The MM information is especially useful for analyzing >21 
(Inconsistent free user memory structure), and >22 
(Inconsistent table area structures) crashes. 

OVB 

For each segment in memory, there is an overhead beet (OVB). 
This command lists all OVBs first by SSB address within the 
segment manager tables 0 and 1. Several of the initial 
segments in this list do not have an OVB associated with 
them (these are segments of resident DNOS). For these 
segments, the beet preceedlng the segment is displayed as 
the OVB, and will appear as an inconsistent structure. Then 
the OVBs are listed in sequence in memory order. This list 
is useful to scan the Integrity of structures when a >21 
(Inconsistent free user memory structure) or >46 
(Inconsistent segment manager structure) crash occurs. 


PBM 

This command displays the contents of the partial bit maps 
for each disk Installed in the current system. It is useful 
when analyzing disk manager crashes. 
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PDT 

The PDT for each device known to the system Is shown. 

PQ 

This command lists the queue server ID and the list of Items 
currently on the queue for each of the following system 
queues : 

* Task bidder 

* I/O Utility 

* Device I/O Utility 

* Disk Manager 

* Task diagnostic (kill task) processor 

* Job Manager 

* IPC task 

* Name Manager 

* User overlay loader 

* Forced roll processor 

* Return code processor 

* System log formatter 

* Accounting log formatter 

The PQ lists usually provide clues to any crash. Most of 
the queues should be empty, except those requiring disk 
access to handle the queue. If other queues are not empty, 
the queue entries and queue servers need to be examined for 
errors. The log queue shows valuable Information, too, 
since It carries the most recent errors sent to the system 
log . 


QU 

This command provides no display. It terminates the 
utility. 

ROB 

All resource ownership blocks are displayed by JSB 
Identifier. 

RPB 

This command prompts for an I/O resource pointer. The 
resource pointer can be an FOB for a file, a PDT for a 
device, or a CCB for a channel. This command then displays 
the RPB along with the other relevant structures. For a 
file. It displays the FDB, FOB, and RPBs. For a device. It 
displays the PDT and the RPBs. For a channel. It displays 
the CCB and the RPBs. 


SGB 

The segment group blocks (SGBs) for all segments currently 
In memory are displayed, first those In table area 0, then 
those In table area 1 . 
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SSB 

All segment status blocks (SSBs) for all segments currently 
In memory are displayed, identified by SGB. 

ST 

The starting address, length, usage, highest address, and 
contents of the secondary table areas are displayed. This 
information is provided for each of the special table areas 
used by segment management and file management and for each 
JCA in the system. 

TA 

A memory area is displayed for each of the tasks currently 
in memory identified by TSB and JSB address. 


The registers are displayed for each task in the system, 
identified by TSB and JSB addresses. 


TS 

A table is displayed, showing the following information for 
each task in the system: 

* TASK NAME - Installed name of the task 

* ID - Installed ID and run-time ID of the task 

* WP - Workspace pointer 

* PC - Program counter 

* ST - Status register 

* STATE - Code for the task state (see DSC . TEMPLATE . 
ATABLE .NFSTAT or the DNOS Messages and Codes Reference 
Manual for details. The first two digits are the 
runtime priority of the task, the second two digits 
are the task state. Tasks in state >04 (terminating) 
may have an inconsistent display as structures may 
have been released. 

* FLAGS - The first word of task flags from the TSB 
of the task 

* STATION - The station ID from the TSB of the task; 
if the task was not bid at a station, no station 
ID is displayed 

* TSBADR ~ The TSB address 

* JSBADR - The JSB address 

* PROG FILE - The name of the program file from which 
the task was bid; only the last portion of the 
pathname is listed 


TSB 

This command displays each of the TSBs for each of the jobs 
whose JCA is currently in memory. 
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? ? 


This command lists all available crash analysis commands. 


17.3 GUIDELINES FOR CRASH ANALYSIS 

It Is Impossible to give a set of rules by which crash analysis 
can be done. There are several general guidelines which should 
be known, and for specific crashes, there are some specific 
guidelines. The following paragraphs address general hints 
first, then some specific suggestions. 

In general, an operating system crash occurs when some data 
structure has been destroyed. The problem In analyzing the crash 
Is then to find what structure has been changed, and what code or 
combination of circumstances changed the structure. To conduct 
such an analysis, you must be familiar with the DNOS data 
structures and be able to detect Inconsistencies. Data structure 
pictures are available In this manual to guide you through the 
structures displayed by the crash analysis utility. In addition, 
you will need to understand as much as you can about how the 
structures are built, used, and released by the relevant DNOS 
subsystems. The subsystem descriptions In this manual discuss 
how they use DNOS data structures. 

The paragraphs which follow give some specific suggestions for 
handling particular crash codes. 

Codes >13 through >1F 

These crashes are for Illegal Interrupts from devices. 
Verify that all devices have been specified at the correct 
Interrupt levels during system generation. If this Is not 
the case, perform a new system generation or change the 
Interrupt level using XSCU. If the devices are at the 
correct Interrupt levels, examine the HARDWARE TRAP VECTOR 
Information given by GI and see that It Is correct. If not, 
you need to find the source of the modification. If the 
Information Is correct, check the workspace for the 
Interrupt (3 through >F) for clues to the crash. 

Code >21 - PMUMGR Inconsistent structure 

Check register 4 In the MACHINE ERROR (TRAP 2) WORKSPACE 
data. It It Is greater than the value In MEMSIZ, a request 
has been made to return memory beyond the end of free 
memory. If the value In Register 4 Is less than UADSTR, a 
request has been made to return memory before the start of 
free user memory. If neither of these Is the case, the free 
memory list Is Incorrect. If register 1 is zero, a block of 
length zero has been specified. If the value at the address 
In register 10 Is greater than MEMSIZ, a block which Is too 
large has been specified. If the value at the address in 
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register 10 is greater than the value in register 11, two 
blocks of memory overlap. If register 4 is less than 
register 0, two blocks will overlap when merged in the free 
list. UADSTR is the start of the free memory list shown by 
the MM command and MEMSIZ is the end of that list. 

Code >22 - NFTMGR inconsistent structure 

Examine the executing stack for the return address of the 
caller of NFTMGR and the address of the item to release in 
that order. 

Code >23 - NFSCHD queueing error 

Register 9 of the EXECUTING WORKSPACE has the TSB address of 
the task that issued the SVC which encountered the error. 
Verify with the TSB address in EXTSB to see that it is still 
valid. Check the last SVC issued by that task to find the 
processor which is in error. 

Code >24 - lOBM Inconsistent structure 

Perform an analysis like that for code >21, using registers 
2 and 4. If register 2 has a value less than BTAADD or 
register 4 has a value greater than UADSTR, a request to 
return buffer space is Incorrect. 

Code >26 “ PMROLL cannot extend the swap file 

This error occurs during task loading; an error indicator is 
in register 0 of the MACHINE ERROR (TRAP 2) WORKSPACE. If 
the error indicator is >30, the file is not extendable. If 
the error is >3F, there is a structure error. If the error 
is >E0, the disk is full. If the error is >DA, the 
secondary allocation table is full. 

Code >29 - NFPOP or NFMAPO unexpected error returned 

Register 11 of the EXECUTING WORKSPACE AT TIME OF DUMP has 
the address of the return. The return context tells which 
location was called. 

Code >2C - NFENAB - scheduler inhibit count is negative 

Register 11 of the MACHINE ERROR (TRAP 2) WORKSPACE points 
to the caller of NFENAB. That routine may or may hot be 
responsible for the error. 

Code >46 - SEGMGR inconsistent structure 

The executing stack has the return address, the caller's 
register 2, and the caller's register 1. Register 1 had the 
address of the SSB to delete. Use this data to detect an 
illegal request. 

End action codes 

Use the TSB list to find the terminating task and examine 
the diagnostic packet which follows the TSB. The DIA 
structure identifies the various fields in this packet, 
showing the error code which caused termination, the 
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workspace pointer, program counter, and status at the time 
end action was taken. 

Codes >60 through >6F - Internal Interrupts 

Examine the return context (R13 - R15) of the Trap 2 

workspace in the GI information for the address of the 
error. Check the stack for recent routine calls and data 
saved. If none of the Information In the GI Information or 
structures lists Is helpful, you might be able to find clues 
to the crash In the Instruction trace kept by the 990/12. 
The 990/12 hardware keeps 32 words of trace Information, 
reflecting the most recent Instruction execution. When an 
internal Interrupt occurs, the Interrupt handler copies the 
hardware trace to the 32 words preceding the scheduler 
workspace In the system root. The address can be calculated 
as 32 less than the start of the SVC ( XOP 15) WORKSPACE 
displayed as part of the GI Information. 


17.4 HARDWARE TRACE INFORMATION 


Hardware trace information for a 990/12 can be found In the 64 
bytes proceeding the SVC (X0P15) workspace. This data must be 
used with caution. Because of optimizations being done by the 
/12, the sequence of hardware instruction pairs may Include 
repetitious data or pairs that appear to logically be out of 
order . 

The format of the trace data Is shown In Table 17-2. These words 
are kept on the processor board for a /12, updated continually 
with every memory cycle. With a level 2 Interrupt, updating 
ceases after the next memory cycle. The Interrupt processor 
dumps this data to memory proceeding the SVC workspace. The 
trace data consists of 16 pairs of words of the form shown here 
as Word 0 and Word 1. The set of entries appears In order of 
latest instruction executed first, something of a pushdown stack. 
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Table 17--2 Format of Hardware Trace Information 


Bit Meaning 

Word 0 

0 Execution violation 

1 TILINE timeout 

2 Memory data error 

3 Mapping error 


Sett Ing 

l = Yes 
l = Yes 
l = Yes 
l = Yes 


4 

5 

6 
7 


Illegal opcode 

Privileged Instruction attempted 
Workspace read/write flag 
TILINE access flag 


l = Yes 
l = Yes 
l=Write 
1 = Acces s 


8 TILINE R/W FLAG l=Wrlte 

9 Workspace access flag 1= Access 

10 Instruction fetch flag l=Fetch 

11-15 Most significant bits of TILINE address 


Word 1 

0-14 Least significant bits of TILINE address 
15 Write violation l=Yes 


The overlap of Instruction execution In the 990/12 often causes 
pairs of Indicators to be set In a word, showing the activity of 
the current Instruction and the last Instruction executed. Some 
typical examples of word 0 might be 

OOCO = Workspace access; TILINE write on previous Instruction 
0100 = TILINE address 
0120 = Instruction fetch 

0160 = Instruction fetch; workspace reference on previous 
Instruction 

OICO = TILINE write; TILINE access on previous Instruction 
02C0 = Workspace write; TILINE write and workspace access on 
previous Instruction 

Note that the TILINE address field Is not cleared from one trace 
pair to the next. Therefore, If the TILINE access flag Is not 
set, the TILINE address Is meaningless. 

Inf orraa tlon given about each of the crash codes In the DNOS 
Messages and Codes Reference Manual might also be helpful In 
resolving the cause of a system crash. Each of the crash codes 
Is described there, with a general indication of Its cause. 
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SECTION 18 

INTERRUPTS AND XOP PROCESSING 


18.1 OVERVIEW OF INTERRUPT PROCESSING 

The 990 computer has sixteen Interrupt levels to serve Interrupt 
requests from various devices and mechanisms. They also have 
sixteen extended operation codes (XOPs) available to allow 
extensions to the standard Instruction set. Users cannot make 
use of the XOP feature, since Texas Instruments software makes 
use of many XOPs and Is likely to use the available set for 
future products. 

Interrupt levels are numbered from 0 through 15, with 0 having 
highest priority. There Is a 4-blt Interrupt mask which stores 
the level number of any Interrupt presently executing and 
prevents Interrupts of the same or lower levels from Interrupting 
the CPU. The mask Is displayed as the last four bits of the 
status register. The mask may be changed by a LIMI instruction 
to enable or disable Interrupts to the desired level. 

Each Interrupt level Is uniquely associated with a two-word 
location In memory, referred to as the Interrupt trap. This pair 
of words includes the workspace pointer and program counter 
values for the program which services the Interrupt. The 
Interrupt traps for DNOS are built during system generation and 
can be found In the sysgen directory In file D$S0URCE (or In Its 
listing form In D$LIST). 

DNOS uses the Interrupt levels as follows: 

* 0 - Power up 

* 1 - Power down 

* 2 - DNOS Internal error 

* 5 - CPU clock 

* Each of the others Is one of: standard device 

Interrupt, expansion chassis Interrupt, multiple device 
Interrupt, undefined Interrupt 

When an Interrupt occurs and Is not masked out by the current 
Interrupt mask value, CPU control Is transferred to the workspace 
and program counter specified In the trap table. If an undefined 
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Interrupt occurs or an internal error is encountered In DNOS, the 
trap table directs the CPU to a system crash routine. In all 
other cases, the Interrupt trap table causes a transfer to an 
Interrupt processing routine. In DNOS, all Interrupt processors 
are found in the system root. 


18.2 OVERVIEW OF XOP PROCESSING 

Extended operations (XOPs) are available on the 990 to build the 
equivalent of machine Instructions not provided in the hardware. 
There are 16 extended operation codes (levels) available. One of 
these, level 15, Is reserved by DNOS for handling supervisor 
calls (SVCs); levels 9 through 12 are used by the DNOS 
performance package, and the remaining levels are reserved for 
future DNOS use. 

When the CPU encounters an XOP Instruction, It tests first to 
determine If a hardware XOP processor is present. If so, control 
Is passed to that processor for execution. If no hardware 
processor Is present, control Is transferred to a software 
routine via a table of processor addresses built during system 
generation. This table Is referred to as the XOP transfer table 
and can be found In the sysgen directory In the file D$S0URCE (or 
in Its listing form In D$LIST). 


18.3 BUILDING AN XOP PROCESSOR 

In special situations, a programmer may wish to Implement an 
Instruction or devise a service of DNOS which Is not available in 
the supplied version of DNOS. To meet these situations, DNOS 
allows the programmer to build his own supervisor calls (SVCs), 
as described In the DNOS Systems Programmer's Guide . In cases 
where this feature Is not sufficient, DNOS system software may 
need to use an XOP processor. 

To add an XOP processor to DNOS, a processor must be written and 
details must be provided during system generation. 


18.3.1 System Generation Requirements for User XOPs. 

The XOP related prompts during system generation are described in 
Table 18-1. The system generation program Inserts the XOP 
processor entry point and workspace address Into the XOP transfer 
table It builds for the system. The system generation program 
also includes the XOP processor object module in the linkstream 
for DNOS. 
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Table 18-1 System Generation Prompts for XOPs 


P romp t 


Response required 


ENTITY? 

XOP LEVEL? 

PC label? 
WP label? 
Pathname ? 


XOP 

Level number (0 through decimal 14) that 
is to be used 

Entry point label of the XOP processor 
Workspace label of the XOP processor 
Name of the file that contains the object 
module for the XOP processor 


18.3.2 XOP Processor Details. 

When an XOP instruction is executed, control transfers to the XOP 
processor via the XOP transfer table. In the workspace of the 
XOP processor, the following registers are loaded and must not be 
destroyed by the processor: 

Register 11 - the address of the XOP operand, 
relative to the calling task address space 

- Register 13 - the requesting task workspace 

pointer 

- Register 14 - the requesting task program counter 

- Register 15 - the requesting task status register 

The XOP processor should execute quickly and be relatively short. 
It cannot issue supervisor calls, but must perform all operations 
locally. It can access the calling task address space by using 
long distance Instructions with the saved map file of the calling 
task. This map file Is at the offset TSBMLl In the task status 
block (TSB) pointed to by the system pointer named EXTSB 
(executing task TSB). Figure 18-1 shows long distance access to 
three parameters from the calling task address space. 

The XOP processor must define (DEF) its entry point and its 
workspace address, and It must reference (REF) the system return 
point, NFTRTN. If It makes use of EXTSB, it must copy two system 
templates, using the following statements: 


COPY DSC. TEMPLATE .ATABLE. TSB 
COPY DSC. TEMPLATE .COMMON. NFPTR 

The first statement copies a template which has the offset TSBMLl 
within a TSB. The second copies a set of system pointers that 
Includes EXTSB. Other data structures might also be accessed by 
an XOP processor. Consult the section on data structure pictures 
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in this manual for details on the structures to be used. 

* 

* THIS EXAMPLE SHOWS HOW AN XOP PROCESSOR 

* INTERFACES WITH THE OPERATING SYSTEM TO ACCESS A CALLER'S 

* TASK AREA AND RETURN TO THE CALLER. THE EXAMPLE IS FOR 

* XOP LEVEL 10, WHERE THE PROCESSOR MOVES N WORDS OF DATA. 

* 

* CALLED BY; XOP @ARGS,10 

* WITH: 

* 

* ARGS DATA X,Y,N WITH X = SOURCE ADDRESS 

* Y = DESTINATION ADDRESS 

* N = NUMBER OF WORDS TO MOVE 

* 

* EQUATES 

* 

COPY DSC. TEMPLATE. ATABLE.TSB TO ACCESS TSB FIELDS 

* GLOBAL DATA 

* 

COPY DSC. TEMPLATE. COMMON. NFPTR TO ACCESS EXTSB 

* 



REF 

NFTRTN 

SYSTEM RETURN POINT 


IDT 

'USRXOP' 



DEF 

USRXOP 

ENTRY POINT FOR SYSGEN RESOLUTION 


DEF 

WPAD 

WORKSPACE ADDRESS FOR SYSGEN 

WPAD 

BSS 

32 

LOCAL WORKSPACE 

USRXOP 

EQU 

$ 

ROUTINE STARTS HERE 


MOV 

@EXTSB,R8 

GET CALLER TSB ADDRESS 


AI 

R8,TSBML1 

POINT TO THE MAP FILE 


LDS 

*R8 

USING XOP OPERAND IN Rll 


MOV 

*R1 1+,R1 

GET ADDRESS OF ARGUMENT X 


LDS 

*R8 



MOV 

*R1H-,R2 

AND ADDRESS OF Y 


LDS 

*R8 



MOV 

*R11 ,R3 

AND OF N 

LOOP 

EQU 

$ 

MOVE N WORDS; ASSUME GOOD ADDRESSES 


LDS 

*R8 

GET A WORD OF SOURCE INFORMATION 


MOV 

*R1+,R4 



LDD 

*R8 

MOVE IT TO DESTINATION 


MOV 

R4 ,*R2+ 



DEC 

R3 

COUNT DOWN 


JNE 

LOOP 

MORE TO DO IF COUNT POSITIVE 


B 

@NFTRTN 

ELSE RETURN TO OPERATING SYSTEM 


END 




Figure 18-1 XOP Processor 
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SECTION 19 
SPECIAL SVCs 


19.1 OVERVIEW 

This set of SVC operations is supported for DNOS operating system 
tasks only. They are not documented In user manuals and must not 
be issued by user-written code. 

Each of the SVC blocks is shown with a hexadecimal offset at the 
left of each word. The upper right of the block shows special 
conditions which must be met, such as alignment on a word 
boundary, if such a condition is relevant. 


19.2 I/O SVCs 


Several of the subopcodes of the I/O SVC can be issued only by 
operating system tasks. They generate error conditions 
otherwise. 


19.2.1 DSRTPD Diagnostics Control (Subopcode >08). 

DSRTPD supports diagnostics control of the communications 
hardware. The mechanism to support this is I/O subopcode >08. 
The extended call block is used for further subopcodes and 
parameters . 

The following functions are supported: 


SUBOPCODE 08 FUNCTIONS 

SUB-SUBOPCODE DESCRIPTION 

56 Write interface image 

66 Read interface image 
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The call block has the following format: 

Hex Offset Align on Word Boundary 

+ + + 


>00 

1 

00 

1 <Return Code> 

1 

>02 

1 

08 

1 LUNO 

•"T 

1 

>04 

"T — * 

1 

<System Flags> | User Flags 

•“T 

1 

>06 

1 


Unused 

1 

>08 

1 


Unused 

“•r 

1 

>0A 

"r — “ 

1 


Unused 

“•p 

1 

>0C 

“r — " 

1 


Unused 

•"P 

1 

>0E 

"T— ■ 

1 


Unused 

“•p 

1 

«4- 

>10 

1 


Par a me ter s 

1 

>12 

“T - 

1 


Parame t er s 

••P 

1 

>14 

T 

1 

Subopcode 

1 Unused 

"T* 

1 


T“" 



“"P 


Byte 

5 , Bit 6 = 

1 (Extension flag) 



Byte 

14, Bit 0 

= Error bit 



19.2.1.1 Write Interface Image. 

Sub-subopcode >56 performs the diagnostic write. The call block 
format depends on the kind of Interface card that Is In use at 
the port. For ports using the COMM INTERFACE board, the format 
Is as f ol lows : 


Byte Description 

10 Bit 0 - Character length select 1 

1 - Character length select 0 

2 - Sync mode selection 

3 - Odd parity select 

4 - Alternate clock select 

5 - Clock select A2 

6 - Clock select A1 

7 - Clock select AO 

11 Modem leads (0=low, l=high) 

Bit 0 - Self test mode 

1 - Transmit break 

2-1=2 stop bits, 0=1 stop bit 
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3 - Echo enable 

4 - Parity enable 

5 - Receiver enable 

6 - Request to Send 

7 - Data Terminal Ready 
Interface Control 

12 Bits 0-7 - Sync character -f Irst load 

DLE character - second load 

13 Bit 0 - Analog loopback 

1 - Half duplex 

2 - Master reset 

3 - Pulsed modem lead out 

4 “ Reserved modem lead out 

5 - Secondary request to send 

6 - Clock select B1 

7 -Clock select BO 

14 Subopcode (>56) 

15 Reserved for board compatibility 


For the TTY/EIA card the format is as follows: 
Byte Description 


10 Modem leads 



Bit 0 - 

Ignored 


1 - 

Data terminal ready 


2 - 

Request to send 


3 - 

Clear read request 


4 - 

Clear write request 


5 - 

Clear new status 


6 - 

Enable Interrupts 


7 - 

Diagnostic mode 

11 

Ignored 


12 

Ignored 


13 

Ignored 


14 

Subopcode 

056) 

15 

Reserved 

for board compatibility 


19.2.1.2 Read Interface Image. 

Sub-subopcode >66 performs the 

di agnos 1 1 c 

read . 

Modem 

interface information Is returned 

in the call 

block as 

follows 

For the COMM board : 

Byte Description 





10 Interface Information 

Bit 0 - Write request 

1 - Interrupt summary 


and 
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2 - Timer expiration 

3 - New status flag 

4 - Scan Busy 

5 - Transmit underrun 

6 - Readable copy of sync selection 

7 “ Read request 

1 1 Modem leads 

Bit 0-1 Unused 

2 - Data carrier detect 

3 - Ring Indicator 

4 - Reserved modem lead out 

5 - Secondary request to send 

6 - Clear to send 

7 - Data set ready 

12 Bits 0-3 - Unused 

4 - Parity error 

5 - Framing error 

6 - Receiver overrun 

7 - Receive error summary 


13 

Bits 0-7 - Receive 

data byte 

14 

Subopcode 


15 

Reserved for board 

compat Ibl 1 1 ty 


For the TTY/EIA board: 

Byte Description 

10 Bits 0-7 - Receive data byte 

11 Modem leads 

Bit 0 - Interrupt 

1 - Data set ready 

2 - Data carrier detect 

3 - Read request 

4 - Write request 

5 - Ring Indicator (cable 2265151-0001) 

reverse channel receive (other cables) 

6 - Timing error (overrun) 

7 - Xml t In progress 

12 Ignored 

13 Ignored 

14 Subopcode 

15 Reserved for board compatibility 


19.2.2 Communications DSR Diagnostics Control (Subopcode >08). 

The DSRs used by communications software use a call block like 
DSRTPD to support diagnostic control of the communications 
hardware. The following functions are supported, using the 
specified subopcodes In the extended call block at offset >14. 
Note that for each subopcode that bits 0 through 3 are defined 
specially for that operation. 
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Sub- Subopcode Meaning 


>X0 

>X1 

>X2 

>X3 

>X4 

>X5 

>X6 

>X7 

>X8 

>X9 

>XA 

>XB 

>XC 

>XD 

>XE 

>XF 


Abort/ Time ou t 

Op en 

Close 

Write 

Read 

Chained write 

Miscellaneous channel commands - diagnostics 

Reserved for Protocol - Immediate 

Reserved for Protocol - data 

Reserved for Protocol - data 

Reserved for Protocol - data 

Reserved for Protocol - data 

Miscellaneous board - data 

Miscellaneous board - Immediate 

Stand-alone diagnostics (not supported) 

Immediate diagnostics 


19.2.3 Open Unblocked (Subopcode >13). 

The Open Unblocked SVC block has the following format: 

Align on word boundary 

it 1 -k 

I 00 1 <Return Code> | 

+ + + 

I 13 I LUNO I 

H — — — — — — — — — — — — — — — — — — 

~ Reserved ~ 

— — — — _ — — _ — — — 

(>0A - maximum size) 

It Is used by I/O utility and several other utilities to access 
files In a special way. This same opcode is used by Unload 
Volume to dump statistics to the system log. In this case, the 
LUNO field Is Ignored and bytes 6 and 7 point to a special area 
designating use of VCATALOG. 


Hex Offset 
>00 

>02 

>04 


19.2.4 Close Without Updating FDR (Subopcode >14). 

The Close Without Updating FDR is used by the directory utilities 
In conjunction with the Open Unblocked operation when copying a 
file. Since the normal copy of a file description record (FDR) 
would change the date of latest modification. It cannot be used 
by the directory utilities. The format of the block is as 
follows : 
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Align on word boundary 


Hex Offset 
>00 

1 

00 

1 <Return Code> 

>02 

1 

14 

1 LUNO 

>04 



Reserved 


A ...... ..A 

(>0A ~ maximum size) 

The Open Unblocked SVC Is used by the directory utilities to 
allow reading of any file as a relative record file. 


19.2.5 DSRTPD Communications Control - (Subopcode >15). 

DSRTPD supports task access to device dependent communications 
control using subopcode >15. The call block Is the same format 
as the Write ASCII subopcode. Further subopcodes and parameters 
are contained Inside the data buffer. Most of these functions 
are also performed by the SCI command MHPC. 


Hex 


Offset Align on Word Boundary 


>00 

+ — 

1 

+_ 

00 1 

<Return Code> 

>02 

1 

15 1 

LUNO 

>04 

T" “ 

1 

<System Flags> | 

User Flags 

>06 

[Buffer Address, Secondary Control Block 

>08 

T — 

1 

Unused (0) 

>0A 

1 

+ — 

Buffer Byte 

Count 


Data Buffer Descriptions 
Byte Value 

0 Subopcode 

1 Reserved (>00) 

2-N Parameters If needed 
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The following functions are supported; with the subopcodes 
indicated being placed in the data buffer. 


Opcode 15 Functions 


Subopcode 


Func t ion 


>16 

>17 

>18 

>19 

>1A 

>1B 

>1C 

>1D 

>1E 


Modify timing characteristics 
Modify line characteristics 
Modify terminal type 
Modify special characters 
Connect 

Flush character queue 
Set file transfer parameters 
Set exclusive access 
Set shared access 


19.2.5.1 Set File Transfer Parameters >1C. 


This command enables selection of a parity checking mode, selects 
timeouts, selects a parity error substitute character, and 
disables the DC3-driven functions: bid, hold output, abort task, 
and timeout. Parameters are located as follows In the call 
block: 


B t ye 


Meaning 


2-3 

4-5 

6 

7, Bit 0 
Bit 1 
Bit 2 
Bits 3-4 


Bit 5 
Bits 6-7 


Primary timeout, read direct 
Secondary timeout, read direct 
Parity error substitute character 
Suppress echo = l , echo = 0 
Unused 

Enable transmit parlty=l 
Transmit parity type 
00=e ve n 
01=odd 
1 0=ma rk 
1 1 =space 

Enable receive parlty=l 
Receive parity type 
(Same as transmit) 


The values so selected disappear when the terminal is 
d 1 s connect ed . 


19.2.5.2 Modify Timing Characteristics >16. 

The default timeouts are changed. Values are gathered from the 
primary control block: 
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Byte 

Value 

(250 ms Increments) 


2-3 

Read 

timeout 



4-5 

Write 

timeout 



6-7 

Read 

direct timeout 

(first 

character ) 

8-9 

Rea d 

direct timeout 

(other 

characters ) 


19.2.5.3 

Modify Line 

Characteristics >17. 

This call 

modifies 

the line configuration with the following 

options : 




Byte 



Value 

2 



LTA character (00=don't change) 

3 



Speed ** 

4, 

Bit 

0 

Half-duplex = 1 


Bit 

1 

Swl t ched 


Bit 

2 

Disabled 


Bit 

3 

Auto-dl s connect enabled 


Bit 

4 

Require DLE+EOT for auto-dlsconnect 


Bit 

5 

SCF ready/busy monitor 


Bit 

6 

Exclusive access 


Bit 

7 

LTA enable (half-duplex only) 


**The following table gives the speed translations for the value 
of byte 20 

Value Speed (ASYNC BPS) 


0 

1 

2 

3 

4 

5 

6 

-1 


no 

300 

600 

1200 

2400 

4800 

9600 

300 or 1200 depending on state of pin 12 
at the COMM I/F. This Is used for automatic 
speed selection in conjunction with VA3400 
and 212A modems. 


19.2.5.4 Modify Terminal Type >18. 


This call allows parameters related to the expected terminal type 
to be altered . 


Byte 


Value 


2 

3, BIT 0 


Terminal model** 
(3=703, 7F=763) 
Echo = 0 
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No echo = 1 

**The following table gives the terminal type translation: 


Value 

Terminal Type 

03 

703 

07 

707 

2B 

743 

2D 

745 

3F 

763 

41 

765 

51 

781 

53 

783 

55 

785 

57 

787 

78 

820 

7D 

825 

.5.5 Modify Special 

Characters >19 


This call modifies the characters used for end of record and end 
of file. 

Byte Value 

2 End of record (00=don't change) 

3 End of file (00=don't change) 


19.2.5.6 Connect >1A. 

This call establishes a connection In the Indicated way. If bit 
0 of the user flags Is set (INITIATE I/O) the task Is not 
suspended pending the establishment of connection. revlslfon bar 
on If the TPD Is not the call originator, DTR Is asserted only 
after Ring Indicator or Data Set Ready Is detected. Once Ring or 
Data Set Ready is detected, the timeout reverts to 10 seconds for 

the completion of the connection. Thus, If a port Is set to 

answer Incoming calls with an Infinite time-out, and some non- 
modem device calls In, the DSR will timeout the call 10 seconds 
after the phone rings. In full-duplex environments. Data Carrier 
Detect must be sensed for the call to complete successfully. 

Byte Value 

2 Assert RTS (00= do not assert) 

3 Assert DTR (00= do not assert) 

4,5 Timeout (250 ms Increments, 0=lnflnlte) 
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19. 2.5.7 Flush Character Queue >1B. 

This call removes any characters buffered In the character queue 
of the KSB. If an extended call block Is used with bit 4 of 
extended user flags set, the DSR Is placed In 8-blt data mode. 
If an extended call block Is not used or If bit 4 Is not set, the 
DSR Is placed In normal mode. 

19.2.5.8 Set Exclusive Access >1D. 

This call places the port under control of file transfer tasks. 
These tasks have bit 5 of the user flags In the PRB set to one on 
opens • 


19.2.5.9 Set Shared Access >1E. 

This call releases the port to tasks that do not have bit 5 of 
the user flags set to one on opens. 


19.2.6 VDT Extended Edit Flags (Subopcode >15). 


Device dependent edit modes for the 911, 931 and 940 VDTs are 
accessed like the DSRTPD Communications Control (Subopcode >15). 
When using subopcode 00 In the data buffer, bytes 2 through 5 of 
the data buffer form 2 words of flags. The following bit setting 
cause the described functions to be performed. 


First flag word (Bytes 2-5 of the subopcode 15 data buffer) 
Bit 0 - 931,940 - enable pass through mode 

1 - 931,940 - In pass through mode, terminate read on 

EXT (>03) 

2 - 931,940 - In pass through mode, terminate read on 

ESC-) pair 

3 - 931,940 - allow extended event characters 

911 - map hardware generated codes 00 ->1F to 
event characters In range >E0 - >FF 

4 - reserved 

5 - 931,940 - allow ESC and SOH characters In Write 

ASCII BUFFER (access to reverse video, 
underline, and blink) 

6 - reserved 

7 - reserved 

8 - 911,915 - report modified data to caller on Read 

ASCII (DSR sets bit 7 of system flags 
byte) 

9 - 911,915 - extended character validation (Invalid 

characters are not echoed, error flag not 
set, beep occurs If warning beep flag Is 
set) 

Suppress null characters on Input, allow 
null character on either 7 or 8 bit Write 


10-911 ,915 - 
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ASCII 

11 “ 911,915 - convert embedded nulls to spaces on Read 

ASCII 

12 - Kanji - toggle screen edit mode and 911 emulation 
13-15 - reserved - must be set to zero 

Second flag word (bit set to 1 Indicates key Is enabled for 
911 and 940 as an event key In the PDT . The existence of the 
second flag word enables its use. (All the Indicated keys 
are mapped to the 913 code, as they would be in the WP mode 
that is no longer available. 


0 Erase Field 

1 Right Field 

2 Left Arrow at left margin 

3 Tab 

4 Down Arrow 

5 Skip 

6 Home 

7 Return 

8 Erase Input 

9 Blank Gray (default anyway) 

10 Delete Character 

11 Insert Character 

12 Right Arrow at right margin 

13 Enter 

14 Lef t Field 

15 Up Arrow (default) 

The first three bits of the first flag word allow the "pure pass- 
thru" support needed to use the 940 in block mode or as a 
replacement for the old SVCs >8 and >18 character mode. These 
functions are not perceived to be particularly useful, but will 
be left in the DSR as a hook to any features not supported by our 
software. An application that uses these functions must restore 
the screen image and terminal state to standard modes on exit 
from pass thru mode. 

Bit 3 (the fourth bit) of the first flag word allows the 3270 
package (and any others) to get at the extended function keys on 
the 940 keyboard. 

Bit 5 allows access to setting the extended display attributes of 
reverse video, underline and blinking. 


19.2.7 Asynchronous Multiplexor Operation (Subopcode >15). 

Two requests for the Modify Device Characteristics SVC (opcode 
>00, subopcode >15) are supported for both VDT and printer DSRs 
that execute on buffered TILINE multiplexers ( Cl 4 0 3/ Cl 4 04 ) . 
These two requests are Read UART Registers and Write UART 
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Registers. These requests are provided for the use of diagnostic 
programs. Their use requires detailed knowledge of the 
CI403/CI404 controllers and the WD8250 UART used on the 
controllers. Refer to the CI403/CI404 hardware documentation for 
more detailed Information. 

The Read and Write UART Registers both directly access the 
functions of slave word 1 of the CI403/CI404 TILINE Peripheral 
Control Space (TPCS). A diagnostic task Is allowed direct access 
to seven UART registers for each channel of the multiplexer. 

19.2.7.1 Write UART Registers. 

The primary function of the Write UART Registers request Is 
setting and resetting specific UART Inputs and RS-232-C signals 
for a diagnostic program. The request Is Implemented by using 
the Modify Device Characteristics SVC (I/O subopcode >15) with 
the sub-subopcode >31. This opcode provides direct, device- 
dependent access to slave word 1 of the CI403/CI404 TPCS. The 
operation must be Issued with an extended call block; otherwise, 
an error Is returned. 

Parameters furnished by the online diagnostic task Include the 
output data buffer length, the contents of the data buffer, the 
UART register number to which the data Is to be written (call 
block byte 18), and the register data (call block byte 19). If 
the device (PDT) to which the operation Is Issued Is not In 
diagnostic mode, the request Is rejected. Figure 19-0 shows the 
call block formats and applicable fields In the Write UART 
Registers request. 
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0 

+- 

1 

>00 1 STATUS BYTE 

-+ 

1 


2 

1 

I/O SUB-OPCODE 1 LUNO 



4 

1 

SYSTEM FLAGS | USER FLAGS 



6 

t 

DATA BUFFER ADDRESS 



1 



8 

1 

1 

RESERVED 

LOGICAL RECORD LENGTH 

1 

1 

1 

1 

1 

10 

1 

character count 

1 

1 

1 

12 

1 

REPLY BLOCK ADDRESS - RESERVED 

1 

1 

1 

14 


EXTENDED USER FLAGS 

1 

1 

1 

16 

1 

1 

RESERVED 

FILL CHARACTER | EVENT BYTE 

1 

1 

1 

1 

1 

18 

1 

REG # 1 RES 1 REGISTER DATA 

1 

1 

20 

1 

1 

RESERVED 

FIELD ROW POS. | FIELD COL POS. 

1 

1 

1 

1 

1 


“T" 


— T 

1 

1 


T"* 

1 

>31 1 IGNORED 

■**T 

|< 

1 

+ 


+ + 

Figure 19-1 Write UART Register Format 


Affected fields of the SVC call block and their meanings are as 
follows : 


Byte Bit 


Meaning 


0 

1 

2 

3 

4 

5 


6,7 


Specifies SVC call type. Enter >00 for I/O. 
Used to return operation error codes. 
Subopcode. Enter >15 for Modify Device 
Characteristics 

LUNO, Use the LUNO from the diagnostic assign. 
System flags. Standard OS definitions apply. 
User flags. Standard OS definitions apply. 

5 Extended call block, 1 = Read or Write UART 

Regl st ers . 

Data buffer address. Points to the buffer that 
contains the sub-subopcode. 
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8,9 

10,11 

18 


19 


Logical record length. Not used. 

Character count. 2 = Read or Write UART Registers. 
7-4 Register number (0-7) left justified in byte. 
Specifies the UART register to which 
the operation is directed. 

Register data. For the Write UART subopcode, 
specifies data to be written. 


19.2.7.2 Read UART Registers. 


The primary function of the Read UART Registers request is 
sensing UART inputs and RS-232-C signals for a diagnostic 
program. The request is implemented by using the Modify Device 
Characteristics SVC (I/O subopcode >15) with the sub-subopcode 
>32. This opcode provides direct, device-dependent access to 
slave word 1 of the CI403/CI404 TPCS. The operation Is issued 
with an extended SVC call block. 

Parameters furnished by the online diagnostic task Include the 
output data buffer length, the contents of the data buffer, and 
the UART register number from which the data is to be read (call 
block byte 18). The register data is returned in call block byte 
19. If the device (PDT) to which the operation is Issued is not 
in diagnostic mode, the request Is rejected. Figure 19-2 shows 
the SVC call block formats and applicable fields in the Read UART 
Registers request. 
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0 

+ 

1 >00 1 

STATUS BYTE- 

1 


2 

1 I/O SUB-OPCODE 1 

1 a. 

LUNO 

1 


4 

1 SYSTEM FLAGS | 

1 . ^ 

USER FLAGS 

1 


6 

1 DATA BUFFER 

ADDRESS 



1 ^ 


8 

1 

[LOGICAL RECORD LENGTH - RESERVED 

I 

1 

1 

0 

1 

1 CHARACTER 

COUNT 

1 

1 

1 

12 

1 

1 REPLY BLOCK 

ADDRESS 

1 

1 

1 

14 

1 

1 EXTENDED USER FLAGS 

1 

1 

1 

16 

1 RESERVED 

1 FILL CHARACTER j EVENT BYTE 

1 

1 

1 

1 

1 

18 

1 

1 REG # 1 RES 1 

REGISTER DATA 

1 

1 

1 

20 

1 

1 RESERVED 

1 FIELD ROW POS. j FIELD COL POS. 

1 

1 

1 

1 

1 


T 


»4- 

1 

1 


“T — — — — ^ — — — — — — — — — * 

1 >32 1 

IGNORED 

K 

1 


H — — — — — — — — — — — — — — — — — — — — — — — — — — — -|. 


Figure 19-2 Read DART Registers Format 


Affected fields of the SVC call block and their meanings are as 
follows : 


Byte Bit 


Meaning 


0 

1 

2 

3 

4 

5 


6 

8 


Specifies SVC call type* Enter >00 for I/O. 
Used to return operation error codes. 
Subopcode. Enter >15 for Modify Device 
Characteristics. 

LUNO. Use the LUNO from the diagnostic assign. 
System flags. Standard OS definitions apply. 
User flags. Standard OS definitions apply. 

5 Extended call block. 1 = Read or Write UART 

Registers. 

Data buffer address. Points to the buffer that 
contains the sub-subopcode. 

Logical record length. Not used. 
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10,11 Character count. 2 = Read or Write UART 

Registers. 

18 7-4 Register number (0-7) left justified in byte. 

Specifies the UART register to which 
the operation is directed. 

19 Register data. For the Read UART subopcode, 

the data read from the device is returned 
in this location. 


19.2.8 TILINE Diagnostic Port (Subopcode >16). 

The TILINE Diagnostic Port operation allows the passing of a 
sixteen byte controller image buffer to a device from a 
nonpri vl leged task. The TILINE controller image after the 
execution of the command is returned in the controller image 
buffer. This subopcode is only valid for disk and magnetic tape 
devices and is used by online diagnostics. 

The call block has the following format: 


Hex Offset 



A1 1 gn 

on Word Boundary 

>00 

1 

0 

1 

<Return Code> 

1 

>02 

1 

16 

1 

Luno 

“T* 

1 

>04 

1 

<Sy stem 

Flags> 1 

User Flags 

1 

>06 

"1““ 

1 

TILINE 

Image Buffer 

Address 

•“T 

1 

>08 

T* 

1 


Reserved = 

>10 

1 

>0A 

1 


Reserved = 

>10 

1 

>0C 

(Binary OS 

Ver/Rell Diagnostic Flags 

“"T 

1 

>0E 

1 

+- 


Dynamic Passcode 

■■T 

1 

-+ 


(>10 - maximum size) 

Byte Description 

3 LUNO assigned to the disk or mag tape 

4 Flags set by system - when set mean; 

Bit 0 - LUNO is busy 

Bit 1 - Error 

Bit 2-7 - Reserved (set to 0) 

5 Flags set by user - when set mean: 
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Bit 0 - Initiate I/O 

Bit 1-6 - Reserved (set to 0) 

Bit 7 - No retries are to be performed 

6-7 Address of TILINE image buffer. This buffer will 

contain the TILINE controller image after the 
command completion. Must begin on word boundary 
and be sixteen bytes in length. 

12 This byte must contain the version and release of the 
operating system in binary. For example, to execute 
this I/O supervisor call on DNOS 1.1, this byte must 
contain the value >11. 

13 Diagnostic flags set by the user - when set mean; 

Bit 0 - 0 = Bytes 10 and 11 in the TILINE 

image buffer do not contain a 
logical address, 

1 = Bytes 10 and 11 in the TILINE 
image buffer contain a logical 
address 

Bit 1-7 - Reserved (set to 0) 

14-15 Dynamic passcode - must contain the current value 

of the system minute. 

When bit 0 of the "diagnostic flags" (byte 13) is set, the 
controller image buffer is modified by the operating system prior 
to execution of the command. In particular, bytes 10 and 11 are 
assumed to contain a logical address; this address is converted 
to a physical 21 bit TILINE address which is inserted into bytes 
10/11 (LSB), and bits 4-7 of byte 13 (MSB) of the TILINE image 
buffer. 


CAUTION 

If the command passed in the TILINE 
controller image transfers data to or from 
the device, it is the responsibility of the 
task issuing the Diagnostic Port operation to 
set bit 0 of the diagnostic flags to 1, and 
provide the logical address (bytes 10 and 11) 
and byte length (bytes 8 and 9) of the 
read/write buffer in the controller image 
buffer . 


The operating system performs address space verification when bit 
0 of the diagnostic flags is set. If this bit is not set, no 


2270512-9701 


19-17 


Special SVCs 



DNOS System Design Document 


address space verification is performed. The address space 
verification checks that the buffer address (bytes 10 and 11) and 
buffer byte length (bytes 8 and 9) fit entirely in one segment of 
the issuing task. Write and execute protection of the segment 
are not checked. 

The unit select field is Ignored in the TILINE controller image 
buffer; the DSR sets the unit select field properly to Indicate 
the device to which the luno is assigned. It should be noted 
that certain fields in the TILINE controller image buffer have 
meaning only after the command is executed. The controller image 
buffer has the following format: 

FOR DISK DEVICES: 


0 

+ 

1 

DISK STATUS 

2 

"T 

1 

COMMAND 

4 

1 

FORMAT/SECTOR 

6 

1 

CYLINDER 

8 

“T 

1 

COUNT 

10 

-T ^ - 

1 

LOGICAL ADDRESS (16 BIT) 

12 

-r * 

1 

SELECT/MSB ADDRESS 

14 

1 

CONTROLLER STATUS 
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0 

2 

4 

6 

8 

10 

12 

14 


+ 

I 

+ 

I 

+ 

I 

+ 

I 

I 

+ 

I 

+ 

I 

+ 

I 

+ 


FOR TAPE DEVICES: 


TAPE TRANSPORT STATUS 


READ OVERFLOW STATUS COUNT 


READ OVERFLOW STATUS COUNT 


READ OFFSET 


COUNT 


LOGICAL ADDRESS (16 BIT) 


COMMAND/SELECT/MSB ADDRESS 


STATUS/CONTROL 


+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 


The following error codes ate unique to the Diagnostic Port. All 
other error codes that occur when using the Diagnostic Port are 
standard SVC error codes. 

Error Meaning 

>00E8 Invalid TILINE Diagnostic Port passcode. The 

passcode is invalid if the following conditions 
are not met in the SVC call block: Byte 8 = >00, 
Byte 9 = >10, Byte 10 = >00, Byte 11 = >10, 

Byte 12 = Binary OS version/release (described 
above). Byte 14-15 = value of system minute. 

>00E9 Invalid TILINE command used with TILINE Diagnostic 

Port . 

The disk DSR handles TILINE Diagnostic Port requests in a unique 
manner. (Other than returning the TILINE controller image, the 
tape DSR does not handle Diagnostic Port requests in a unique 
manner.) The disk DSR Insures that no requests are outstanding 
on any of the devices attached to the same controller (as the 
device receiving the request), before issuing the Diagnostic Port 
operation. After all outstanding requests are completed, the 
Diagnostic Port operation will be initiated. Following the 
completion of the Diagnostic Port operation, all requests queued 
to the devices attached to the same controller are initiated. 
During the interval between the receipt of a Diagnostic Port 
request and the completion of that request, no other requests 
will be initiated to any device attached to the same controller. 
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CAUTION 

Because the disk DSR was not designed to 
handle seek and restore commands Initiated by 
the user, a seek or restore command should 
never be Issued In the TILINE image buffer. 
System error conditions will result If a seek 
or restore Is Issued. 


19.2.9 Read with Initial Value (Subopcode >17). 

The Read with Initial Value subopcode is implemented for the 911, 
931 and 940 devices. This operation performs the same functions 
as Read ASCII, except that the field Initial value Is taken from 
the user's buffer rather than from the terminal display memory. 
When using this operation, the user must rationalize any 
discrepancies between the visible Initial value In the field and 
that which Is passed to the DSR In the buffer. The operation Is 
used by 3270 communications software. 

The following call block Is used: 


Dec 

0 

Hex 

0 

4_« 




Align on Word 

Boundary 

1 


00 

1 

<Return Code> 

1 

2 

2 

1 

-l--i 


17 

1 

LUNO 

1 

4 

4 

1 

4-- 

<System Flags> 

1 

User Flags 

1 

6 

6 

1 


Data Buffer 

Addre s s 

1 

8 

8 

1 


Read Character 

Count 

1 

-L 

10 

A 

“T" 

1 


<Actual Read 

Count > 

1 

J- 

12 

C 

1 


Validation 

Table Address 

-1- 

1 

14 

E 

T“ 

1 


Extended 

User Flags 

1 

J. 

16 

10 

1 

4-.I 

Fill Character 

i 

<E ve nt / By t e > 

1 

18 

12 

1 

4-. 

Cursor 

Position Row 

1 

Column 

1 

20 

14 

1 

4-- 

Field 

Beginning Row 

1 

Column 

1 



016 

- Maximum size) 





Byte 

04 System flags 
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05 

08-09 

OA-OB 

OC-OD 

OE 


OF 


11 


0 - Busy 

1 - Error 

2 - EOF 

3 - Event 

7 - Modify data tag (operator pressed a valid 
data key or erase key) 

User flags 

5 - Extended block - must be set 1 

Output character count on Initial read option - 

size of Initial value In the buffer 

Actual count of characters read (always less than 

or equal to size of Initial value) 

Specify the address of a validation table If 
character validation Is set In the extended user 
flags. Otherwise set to zero. 

Extended user flags 

0 - Field start position 

1 - Intensity 

2 - Blink cursor 

3 - Graphics 

4 - Elght-blt characters (Intensity bit) 

5 - Task edit 

6 - Beep 

7 - Right boundary 
Extended user flags 

0 - Cursor position In read field 

1 - Fill character 

2 - Do not Initialize field 

3 - Require termination char for return 

4 - No echo 

5 - Character validation 

6 - Ignored 

7 - Warning beep 

Programmable key or blank returned 


The "do not Initialize field" flag set to 1 Indicates that the 
DSR will not replace the data on the screen by what Is In the 
buffer before doing the Read operation. 


19.2.10 Assign Diagnostic Device (Subopcode >94). 

The Assign Diagnostic Device Is Issued by a task that Is 
assigning a LUNO to a device that Is In the diagnostic state. 
The call block Is of exactly the same format as the Assign LUNO 
(subopcode >91); but subopcode >94 Is required to assign a LUNO 
to a device that Is In the diagnostic state. Only one task can 
successfully execute this SVC at any one time. Other tasks 
attempting the assign will receive a >9C error. 
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19.2.11 Attach File (Subopcode >A0) . 

The Attach File SVC Is used to reserve access to a file. The FCB 
representing the file to be attached Is built (or located If 

already In memory). The SVC Is currently used, by the O.S. to 

support job local temporary files. 

If the request Is the first attachment to this file by this job, 

an ROB Is built to point to the FCB representing the file. An 

attachment number between 0 and 255 (unique to this job) Is 
generated and placed In the ROB. (See the discussion of Detach 
File by Number SVC for details of its use.) The LUNO count for 
the FCB is Incremented. 

If the File was already attached by this job, the count of attach 
operations In the ROB is Incremented. 

The Attach Resource SVC block has the following format: 

Align on word boundary 


Hex Offset 
>00 

* 

1 

00 

1 <Return Code> 

-* 

1 

>02 

1 

AO 

1 Reserved 

1 

i»4. 

>04 

~ 




>06 



Reserved 


>16 

1 

Pathname Pointer 

“*T 

1 

>18 



Rese rved 



* 

(>24 - maximum size) 


* 
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19.2.12 Detach File (Subopcode >A1). 

The format of the Detach File SVC call block is as follows: 


Align on word boundary 

Hex Offset * 1 * 

>00 I 00 1 <Return Code> | 

>02 I A1 I Reserved | 

+ + + 

>04 ~ Reserved ~ 

H — — — — — — — — 

>08 I JSB Address | 

+ + 

>16 I Pathname Pointer | 

+ + 

>18 ~ Reserved ~ 

(>24 “ maximum size) 


If the JSB field Is zero, the file Is detached from the Issuer's 
job. In order to specify another job, the Issuing task must be 
software privileged, hardware privileged or a system task. The 
ROB associated with the JCB which corresponds to the given 
pathname Is located. If more than one attach has been Issued, 
the attach count is decremented and control is returned. If the 
attach count is zero, the ROB Is deleted and the FCB luno count 
Is decremented. When the luno count Is zero the memory 
structures are released, and If the file was a temporary file. It 
is deleted. 
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19.2.13 Detach File by Number (Subopcode >A3). 

The Detach File by Number SVC call block has the following 
forma t : 

Align on word boundary 

Hex Offset * H * 

>00 I 00 I <Return Code> | 

+ + + 

>02 I A3 I Detach Number | 

+ + + 

>04 I Reserved I 

+ + 

>06 I Reserved I 

+ + 

>08 I JSB Pointer | 

H — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -f- 

>0A ~ Reserved ~ 

■k * 

(>24 - maximum size) 

The Detach File by Number SVC is Issued by the Job Manager for 
each ROB that still exists for a job at its termination. Job 
Manager obtains the attach number from the ROB and places it into 
byte 3 of the Detach File by Number call block. 
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19.2.14 Modify FDR Bit (Subopcode >A4). 

The Modify FDR Bit SVC is available to turn on or off a 
particular bit in an FDR. One of the flags in the call block 
Indicates which bit to change and another flag indicates how to 
change that bit. 

The format of the SVC call block is as follows: 


Align on word boundary 

Hex Offset * 1 * 

>00 I 00 I <Return Code> | 

H — — — — — — — — — — — — — — 

>02 1 A4 I Reserved I 

+ + + 

>04 I <System Flags> | User Flags | 

-I — - — I- 

>06 ~ Reserved ~ 

+ -+ 

>16 1 Pathname Pointer | 

>18 ~ Reserved 

-* 

(>24 “ maximum size) 


Byte5“userflags 

Bit 0 l=Set , 0=Clear specified bit 

Bit 1 l=Use temporary file bit 

Bits 2-7 Reserved, must be zero 
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19.2.15 Release LUNO in Another Job (Subopcode >A5). 

The Release LUNO In Another Job SVC Is used by the Job Manager 
and by PMTERM to clean up job-local and task-local LUNOs when a 
job or task terminates. 

The format of the SVC call block is as follows: 


Hex Offset 
>00 

* - 



Align on word boundary 

1 


00 

1 <Return Code> | 

>02 

1 


A5 

1 LUNO to Release | 

>04 

1 

<System 

Flags> 1 Reserved | 

>06 

“T* 

1 



Reserved | 

>08 

"r“ 

1 

JSB 

of 

job from which to releasel 

>0A 

1 

TSB 

of 

job from which to release] 

>0C 




Reserved ~ 

>10 

•T“ 

1 



Utility Flags | 

>12 




RESERVED 

(>24 

* - 

maximum 

size) 
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19.2.16 Assign System LUNO FF (Subopcode >A6). 

The Assign System LUNO FF - Is used to create a logical device 
table (LDT) for a given program file, using Its file control 
anchor (FCA). The format of the block Is as follows: 


Align on word boundary 

Hex Offset * -H — * 

>00 I 00 I <Return Code> | 

+ + + 

>02 I A6 I Reserved I 

+ + + 

>04 ~ Reserved ~ 

H — — — — — — — — — — — — — — — — — 

>08 I FMT Address | 

>0a I FOB Address | 

— . — _ — — — — — — — — — A 


(>0C - maximum size) 
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19.2.17 Release File Structures (Subopcode >A7). 


The Release File Structures operation Is used by the I/O 
subsystem to remove file structures during certain abort 
conditions. It releases file control block (FOB), and the file 
directory block (FDB). The format of the block Is as follows: 


Align on word boundary 

Hex Offset * H * 


>00 

1 

00 

1 Reserved 

>02 

1 

A7 

1 Reserved 

>04 



Reserved 

>08 

1 


FMT Address 

>0A 

1 

* 


FDB Address 


(>0C - maximum size) 


19.2.18 DIOU Operations (Subopcodes >C2, >C3, >C6, >C7). 

The DIOU operations use a call block described In a template 
named DCB. It Is designed to simplify any buffering and 
unbufferlng that has to be performed by placing the string field 
at the same location as the string field of the IRB (pathname 
field). The subopcodes that use the DIOU call block are: 

>C2 - Get selected device parameters 
>C3 - Set selected device parameters 
>C6 - Get CDE From CDT 
>C7 - Process device task bid 
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The DIOU Call Block (DCB) Hars the following format: 


^Ign^on Word Boundary 

Hex Offset * * 

>00 ! 00 I TReturn Code>! 

+ + + 

>02 ! DCBOC -■ ! DCBLUN ! 

+ ■ +-- + 

>04 ! DCBSFL ! DCBCDE ! 

>06 ! Reserved ! 

+ + + 

>08 ! DCBNAM ! ! 

I I / 

/ / / 

>10 ! Reserved ! 

+ +- + 

>12 ! DCBNUM ! 

+ + + 

>14 ! DCBUFL ! 

+ ; + + 

>16 ! DCBBUF ! 

+ + — + .. 

( >18 ” maximum size) 

FLAGS FOR FIELD: DCBSFL #04 - ^SYSTEM FLAGS 

DCFBSY = (X ) - BUSY 

DCFERR = ( .X ) - ERROR 

FLAGS FOR FIELD: DCBUFL #14 - ^REQUESTOR FLAGS 

DCFCON = (X ...) - CONDITIONAL SET 

DCFNAM = (.X ) - NAME SPECIFIED 

DCFRES = (..X ) - RESERVED FLAG 

DCFWCH = (...XX ) - WHICH RELATIVE DEVICE 

DCFREP = ( X ) - REPLACE 

DCFVOL = ( X ) - VOLUME NAME PROVIDED 

DCFSDK = ( X ) - USE SYSTEM DISK 


EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 
DCBCHR DCBCDE >05 *BID CHARACTER 
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DCBOC 

The operation code of the desired SVC Is placed in this byte 
by the requester. The value returns unaltered. 

DCBSFL 

DCFBSY, when set to 1, indicates the SVC is being worked on. 
DCFERR, when set to 1, indicates an error was returned in 
DCBEC. 

DCBCDE 

All operations that require a CDE number (position within a 
CDT) get the number from this field. If the first CDE is 
desired this field is 0, second CDE is 1, and so on up to 
>F. 

DCBCHR 

DCBCHR is an equate for the DCBCDE field. The bid character 
on a bid task SVC is placed in this field. 

DCBNAM 

Up to eight character, left-adjusted, blank filled name of 
the device. This is provided by the requestor when DCFNAM 
is set to 1 for the SVCs that require a device name or 
number. It is filled in by DIOU when a device name is 
reques t ed . 

DCBNUM 

The DIOU assigned number for the device. It is returned by 
DIOU when a device number is requested. It is provided by 
the user when DCFNAM is set to 0 for the SVCs that require a 
device name or number. 

DCBUFL 

DCFCON, when set to 1, indicates that the operation being 
performed is a Conditional Set Parameters. DCFNAM, when set 
to 1, indicates the name of the device is specified in the 
call block. When set to 0 the device number is specified. 
DCFWCH is a two bit flag that is used by the Get Device 
Parameters operation to indicate the parameters of the 
specified device are desired (00), or the parameters of the 
device that is lexically less than (01) or greater than (10) 
the specified device are desired. DCFREP is used when 
modifying a CDT. If DCFREP is set to 1, the specified CDE 
will replace the current CDE of that number. If DCFRGP is 
set to 0, the specified CDE will be added to the CDT only if 
none currently exists with the same CDE number. DCFVOL is 
set to 1 if a volume name instead of a disk name is provided 
in the call block. DCFSDK is set to 1 if the operation is 
applied to the system disk. The order in which DCFSDK, 
DSFVOL, and DCFNAM are checked is DCFSDK, DSFVOL, and then 
DCFNAM. In other words, DCFSDK overrides DCFVOL and DCFNAM, 
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and DSFVOL overrides DCFNAM. 

DCBBUF 

The address of the device parameters or the CDE, depending 
on the subopcode. The address may be odd. When a buffer is 
used, the first byte contains the length of the buffer 
excluding the length byte. 

19.2.18.1 >C2 - Get Selected Device Parameters, 

The Get Selected Device Parameters operation return the values of 
the parameters Identified in the buffer pointed to by the DCBBUF 
field. The name and number of the device are always returned In 
the call block when this operation completes successfully, 

DCB fields used include: DCBOC (>C2), DCBNUM, DCBNAM, DCBUFL, 
and DCBBUF. 

DCBNUM 

If the DCFNAM flag (see DCBFLG) is 0, the parameters 
requested are those of the device specified by the device 
number in this field. If it Is 1 the device number will be 
returned In this field even If It Is not one of the 
parameters requested. 

DCBNAM 

If the DCFNAM flag Is 1, the parameters requested are those 
of the device specified by the device name In this field. 
If It Is 0, the device name will be returned in this field 
even if It Is not one of the parameters requested. 

DCBUFL 

If the DdFNAM flag is 0, the number in the device number 
field Identifies which device's parameters are requested; 
otherwise, the name In the device name field does. The 
DCFWCH flag field Indicates which device's parameters 
relative to the specified one are to be returned. If the 
field is 00 use the specified device, 01 use the device that 
Is lexically less than the specified device, or 10 use the 
device that Is lexically greater than the specified device. 

DCBBUF 

The buffer pointed to by this field Is set up by the user in 
the following manner. 


length of 
parame ter 
par ame ter 

the buffer 
number of a 
number of a 

• 

parame ter 
parame ter 


parame ter 

• 

• 

numbe r 

0 

of a 

parameter 
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All of the values are bytes. The length of the buffer Is the 
total number of bytes available for DIOU to place the specified 
parameters back Into the buffer. If the name or number parameter 
Is In the list of parameters the value will not be returned In 
the buffer but Instead It will be placed In the name or number 
field of the call block. The buffer will be returned using the 
following format. 

length of the buffer 
parameter number of a parameter 
length of the parameter 
parameter 


0 

The length of the buffer will be the number of bytes taken up by 
the parameter overhead ( on'e word per parameter) and the 
parameters. It will Include a byte for the 0 terminator. If a 
parameter Is not defined, the length byte for that parameter will 
be zero. 


I 

J- repeated 
+ 


19.2.18.2 >C3 - Set Selected Device Parameters. 

The Set Selected Device Parameters operation adds or changes the 
values of the parameters Identified In the buffer pointed to by 
the DCBBUF field. 

DCB fields used Include; DCBOC (>C3), DCBNUM, DCBNAM, DCBUFL, 
and DCBBUF. 

DCBNUM 

If the DCFNAM flag (see DCBFLG) Is 0, the parameters to be 
set are those of the device specified by the device number 
In this field. 

DCBNAM 

If the DCFNAM flag Is 1, the parameters to be set are those 
of the device specified by the device name In this field. 

DCBUFL 

If the DCFNAM flag Is 0, the number In the device number 
field identifies which device's parameters are to be set, 
otherwise; the name in the device name field does. If the 
DCFCON flag is 1, the parameters in the list will be set If 
the verification value provided with the new value Is the 
present value of the parameter. 

DCBBUF 

If DCFCON is 0, the buffer pointed to by this field will be 
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set up by the user In the following form. 

length of the buffer 
parameter number of a parameter 
length of the parameter 
parameter 


0 

DIOU processes the buffer until It encounters a 0 parameter 
number or the end of the buffer as defined by the first byte of 
the buffer. The length byte does not include Itself. 

If DCFCON Is 1 , the buffer pointed to by this field Is set up by 
the user In the following form. 

length of the buffer 
parameter number of a parameter 
length of the parameter 
verification value 
par ame ter 


0 

The verification value must be the same length as the parameter. 
DIOU processes the buffer until It encounters a 0 parameter 
number or the end of the buffer as defined by the first byte of 
the buffer. The length byte does not Include Itself. Note that 
only those parameters not declared as READ ONLY may be altered. 


19.2.18.3 >C6 “ Get CDE From CDT. 

The Get CDE From CDT operation returns the requested command 
definition entry from the specified command definition table. 

DCB fields used include; DCBOC (>C6) , DCBCDE, DCBNUM, and 
DCBBUF. 

DCBCDE 

This field contains a value between 0 and >F that Identifies 
the CDE to be retrieved. 

DCBNUM 

The CDT number from which the CDE Is to be retrieved is 
placed in this field. The first CDT Is number 0. 


I 

|- repeated 
I 


1“ repeated 
+ 
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DCBBUF 

The CDE Is returned In the buffer pointed to by this field. 
The first byte will be the length of the CDE. 


19.2.18.4 >C7 - Process Device* Task Bid. 

The Process Device Task Bid operation processes the CDE 
corresponding to the character passed In the call block If the 
character Is In the specified terminal's CDEs. 

DCB fields used Include: DCBOC (>C7) , DCBCDE, DCBNUM, DCBNAM, 
and DCBUFL. 

DCBCDE 

The character of a CDE. 

DCBNUM 

If the DCFNAM flag (see DCBFLG) Is 0, the task bid Is from 
the device specified by the device number In this field. 

DCBNAM 

If the DCFNAM flag Is 1, the task bid Is from the device 
specified by the device name In this field. 

DCBUFL 

If the DCFNAM flag Is 0, the number In the device number 
field Identifies which device the task Is bid from; 
otherwise, the name In the device name field Identifies the 
device. 


19.3 SPECIAL FEATURE OF EXECUTE TASK SVC 


The Execute Task SVC (>2B) uses a bit In the flag byte of the 
call block for Implementing the RBID function. When the bit Is 
set, the SVC processor bids the task and unconditionally suspends 
the caller. The caller Is placed In state 6, as opposed to state 
17. This allows the task that Is bid and the task that bid It to 
alternate execution. When the task that was originally bid 
terminates, the caller is reactivated. 

The sole function of the FBID bit Is to support the SCI RBID 
capability. The RBID process Is described In detail In the DNOS 
SCI and Utilities Design Document . 
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19.4 SEGMENT MANAGEMENT 


The Reset Exclusive Use Across Job Boundaries suboperation (>13) 
of the Segment Management SVC (>40) Is used by the task 
termination processor (PMTERM) to clean up any segments still 
owned at task termination. PMTERM will continue to Issue this 
SVC as long as there are owned segment entries (OSEs) linked to 
the TSB. This operation uses the same SVC processor as the Reset 
Exclusive Use suboperation but uses a different entry point. If 
the task In which exclusive use Is being reset Is not In state 04 
(task termination), the SVC will fall. Otherwise, the segment 
owner block (SOB) Is delinked' from the SSB and Its memory 
released. The OSE Is removed from the list of owned segments 
linked to the TSB and Its memory released. If the segment Is not 
In use or reserved. It Is cached or deleted. 


19.5 NAME MANAGEMENT 


The Name Management SVC (SVC >43) supports 15 subopcodes, most of 
which are not useful to user programs. Four of the operations 
are documented In the DNOS SVC Reference Manual . These are: 

* Return the pathname and parameters for a logical name 

* Create a logical name (Setting a name's value) 

* Delete a logical name 

* Restore name segment 

The following operations are documented only In this section, 
since they are useful only to operating system and DNOS utility 
tasks : 

* Return an additional pathname of a set of pathnames for 
a logical name 

* Add a pathname to the set of pathnames for a logical 
name 

* Return the logical name that Immediately precedes or 
follows In alphabetical order the specified logical name 
In the current stage 

* Delete a defined subset of the logical names In the 
current stage 

* Create a new stage 
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* Return to the previous stage 

* Return error Information 

* Return segment size 

* Copy logical names to new segment 

* Create empty name segment 

* Save name segment 

A task that requires a new logical name performs a Set Name's 
Value (subopcode >02) operation, supplying the logical name, the 
value (pathname), and the parameters. If any. When the value of 
a logical name Is a set of pathnames, the task performs an Append 
Pathname to Name (subopcode >03) operation, supplying the logical 
name and a pathname. The append operation Is performed for each 
additional pathname. 

When a task needs the pathname or parameters of a logical name. 
It performs a Determine Name's Value (subopcode >00) operation. 
When the value of the logical name Is a set of pathnames, the 
task performs a Determine Next Pathname (subopcode >01) operation 
for each additional pathname. The task supplies the logical name 
for either of these two operations. Within DNOS, most Assign 
LUNO operations go through the Name Manager for resolution of 
names, therefore a task rarely needs to use this operation. 

The Delete Name (subopcode >04) operation deletes a specified 
logical name. The Return Next Name (subopcode >05) operation 
returns a logical name that Is adjacent to the supplied name In 
the current name list. A flag specifies the preceding name or 
the following name. 

The Purge Names (subopcode >06) operation supplies a logical name 
and Its length. The name Is compared to each logical name In the 
current name list. If an equal name Is found, that name Is 
deleted. When all but the rightmost character of the names are 
equal, and the rightmost character of the name In the table Is 
greater than the corresponding character of the specified name, 
the operation deletes the name. 

The Enter New Stage (subopcode >07) operation creates a new stage 
with the calling task as the only task In the stage. The Return 
to Previous Stage (subopcode >08) operation may only be executed 
by the task that created the current stage. It returns that task 
to the previous stage of the task. It deletes the stage If It 
has no daughter stage and If the calling task Is the only task In 
the stage . 

The Return Next Error Entry (subopcode >09) returns the values of 
error synonyms stored In the first entry In the list of error 
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ent rles . 

Several operations have to do with the segments that contain 
logical names and synonyms. The Determine Segment Size 
(subopcode >0A) operation returns the size required for a segment 
that would hold the names available to the calling task. The 
Copy Names to New Segment (subopcode >0B) operation copies all 
names available to the calling task to the specified segment. 
The Create Empty Name Segment (subopcode >0D) creates a new 
segment for names and Save Name Segment (subopcode >0E) copies 
the name segment to disk. The Restore Name Segment (subopcode 


>0C) retrieves a disk copy of a name segment Into memory. 

The supervisor call block is of the following form: 

Align on word boundary 

Hex Offset * H * 

>00 I >43 I <Return Code> 1 

+— — — — — — — — — — — _ — — — — — ———I- 

>02 I Subopcode | Flags | 

+ + + 

>04 I Address of Name | 

+ + 

>06 I Address of Value | 

+ + 

>08 1 Address of Parameter List I 

-j — 

>0A I Miscellaneous | 

^ 

>0C I Reserved | 

* ic 

The call block contains the following: 

Byte Contents 

0 Opcode , >43 . 

1 Return code. DNOS returns zero when the operation 


completes satisfactorily. When the operation 
completes In error, DNOS returns an error code. 
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2 Subopcode, as follows: 

>00 ~ Determine Name's Value 

>01 - Determine Next Pathname 

>02 - Set Name's Value 

>03 - Append Pathname to Name 

>04 “ Delete Name 

>05 “ Return Next Name 

>06 - Purge Names 

>07 - Enter New Stage 

>08 - Return to Previous Stage 

>09 - Return Next Error Entry 

>0A - Determine Segment Size 

>0B “ Copy Names to New Segment 

>0C - Reserved 

>0D - Create Empty Name Segment 
>0E - Save Name Segment 
>0F - Restore Name Segment 

3 Flags : 

Bit 0 - Name type. Set as follows: 

1 - Logical Name 
0 - Synonym 
Bits 1-7 - Reserved 

4-5 Address of name. Address of a buffer that contains 

the name (or name list for the return to previous 
stage operation). The first byte of the buffer 
contains the length of the name (or name list). 

6-7 Address of value. Address of a buffer that contains 

a pathname or other value for a logical name. The 
first byte of the buffer contains the length of the 
pathname . 

8-9 Address of parameter list. Address of a buffer that 

contains a parameter list for a logical name. The 
first byte of the buffer contains the length of the 
list. 

10-11 Miscellaneous. Used as a flag by the determine name's 

value and the return next name operations. Used for 
the parameter number by the determine next pathname 
operation. Used for the segment size by the determine 
segment size operation. Used for segment ID by the 
copy names to new segment operation. 

12-13 Reserved. 
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The task that requests a Set Name's Value operation for a logical 
name with parameters must supply the parameters in a list. The 
Determine Name's Value operation returns a parameter list also 
when the name Is a logical name having a parameter list. The 
format of the parameter list Is as follows: 


Hex Offset 

*. 

00 

1 

+■ 

02 

1 

+■ 

04 

1 

2+n 

1 


+ 

4+n 

1 

+ 

6+n 

1 

4+n+m 

1 



Length 1 

J_ _ 

0 


1 


Type 

for 

Sublist 1 Length 

of 

Sublist 

1 

Required 






1 



Parame ter 
Entry Blocks 



1 

1 

^ 4 - 


Type 

f or 

Sublist 1 Length 

of 

Subll s t 

1 




Parameter 
Entry Blocks 



1 

1 

Optional 






1 

-* 



The parameter list contains the following: 
Byte Contents 

0 


Length. Length of entire structure; the sum of 
1 plus twice the number of sublists. 


1 Zer o . 

One or more of the following sublists: 


2 Type for sublist. The type of the parameters In 
the sublist. Types of parameters are: 

0 - System parameters 

1 - Spooler parameters 
2->7F - Reserved 

>80->FF - User IPC parameters 

3 Length of sublist. The sum of the lengths of all 
parameter entry blocks In the sublist, referred 
to as n . 

4-3+n Parameter entry blocks, one for each parameter. 

Formats of parameter entry blocks are described 
in subsequent paragraphs. 

Three formats are defined for parameter entry blocks, any of 
which may be used for any type of parameter. The three formats 
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are related to three parameter sizes. A parameter may be a 
single-bit binary value (a flag, for example), or It may be a 
value that can be stored in one byte, or It may be a value that 
occupies more than one byte. Each format Includes a parameter 
number, and one or two bits that Identify the format. The 
parameter entry block format for a single-bit value Is: 

* — +-+-* 

I Parameter No. |1|V| 

4.. :l\; 

The parameter entry block contains the following: 

Byte Contents 

0-5 Parameter number, 0 through 63. Parameter numbers 

need not be assigned or ordered in sequence, but 
must be unique within the sublist. 

6 1 

7 Va lue , 0 or 1 . 

The parameter entry block format for a one-byte parameter Is: 

I Parameter No. |0|0| 

I Value I 

* A 

The parameter entry block contains the following: 

Byte Contents 

0 Parameter number byte: 

Bits 0-5 - Parameter number, 0 through 63. 

Parameter numbers need not be assigned 
or ordered In sequence, but must be 
unique within the sublist. 

Bit 6 - 0 
Bit 7 - 0 

1 Value. A numeric value, 0 through 255, or an ASCII 
character . 
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The parameter entry block format for a multi-byte parameter Is: 

I Parameter No. 10|11 

I Parameter Length | 

+ + 

I I 

~ Parameter 

~ Value 

I I 

The parameter entry block contains the following: 

Byte Contents 

0 Parameter number byte: 

Bits 0-5 - Parameter number, 0 through 63, 

Parameter numbers need not be assigned 
or ordered In sequence, but must be 
unique within the subllst. 

Bit 6-0 
Bit 7 - 1 

1 Parameter length. The number of bytes required 
for the parameter value. 

2-nn Parameter value. The numbers or characters of 

the parameter. 

The parameter list consists of one or more subllsts. All 
parameters In a subllst are of the same type. When the list 
contains only one subllst, the parameters of that subllst may be 
of any type. Each parameter Is defined In a parameter entry 
block, the format of which depends on the size of the parameter. 
Each parameter Is Identified by a parameter number In the range 
of 0 through 63. The parameters In a subllst must have unique 
parameter numbers. They may be numbered In any sequence, 
skipping numbers, or not, as required. 


19.5.1 Determine Next Pathname (Subopcode >01), 

When the Determine Name's Value operation returns 1 In the 
miscellaneous field, the task executes one or more Determine Next 
Pathname operations (subopcode >01). Each operation returns a 
pathname and Indicates whether or not there Is another pathname. 
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The following fields of the supervisor call block apply: 

* Opcode - >A3 

* Return code 

* Subopcode - >01 

* Flags 

* Address of name 

* Address of value 

* Miscellaneous 

The operation Is defined only for logical names. The flag for 
name type must be set to 1 . 

The address of name field must contain the address of a buffer 
that contains the length of the name In the first byte, and the 
characters of the logical name In succeeding bytes. 

The address of value field must contain the address of a buffer 
large enough to contain the pathname expected. The first byte In 
the buffer contains the length of the buffer. The operation 
replaces that value with the length of the pathname, and places 
the characters of the pathname In succeeding bytes. 

The miscellaneous field contains the number of the next pathname 
(the pathname to be returned). Pathname 0 Is the first pathname, 
pathname 1 Is the second, etc. The operation increments the 
number, or sets the field to zero when the last pathname Is 
returned . 


19.5.2 Append Pathname to Name (Subopcode >03). 

When a logical name represents a set of pathnames, the Append 
Pathname to Name operation (subopcode >03) adds the pathnames, 
one at a time. The logical name must have been created, and must 
have a pathname and parameters (If required) prior to performing 
this operat Ion . 

The following fields of the supervisor call block apply: 

* Opcode - >43 

* Return code 

* Subopcode - >03 

* Flags 
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* Address of name 

* Address of value 

The operation Is defined only for logical names. The flag for 
name type must be set to 1 . 

The address of name field must contain the address of a buffer 

that contains the length of the name In the first byte, and the 

characters of the logical name in succeeding bytes. 

The address of value field must contain the address of a buffer 

that contains an additional pathname. The first byte In the 

buffer contains the length of tbe pathname. Successive bytes 
contain the characters of the pathname. Pathnames for files 
being concatenated must be unique. 


19.5.3 Return Next Name (Subopcode >05). 

The Return Next Name operation (subopcode 05) returns the next 
logical name and, optionally, the pathname of the logical name. 
The next logical name Is either the preceding or following name 
In alphabetic order, selected by a flag supplied In the call 
block . 

The following fields of the supervisor call block apply; 

* Opcode ~ >43 

* Return code 

* Subopcode - >05 

* Flags 

* Address of name 

* Address of value 

* Miscellaneous 

When the name type flag In the flags byte is set to zero, the 
operation expects the name to be a synonym, and returns a 
synonym . 

The address of name field must contain the address of a buffer 
that contains the length of a name In the first byte, and the 
characters of that logical name In succeeding bytes. The buffer 
may contain zero In the first byte when no logical name Is 
supplied. The operation returns the first name In alphabetical 
order when no logical name Is supplied. 
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The operation returns the next logical name In the buffer at the 
address In the address of name field. When the next logical name 
does not exist, the operation returns a zero In the first byte of 
the buffer. This buffer must be large enough to contain an 
eight-character logical name. 

The address of value field must contain the address of a buffer 
In which the operation returns the pathname. When the calling 
task places zero In the first byte of this buffer, the operation 
does not return a pathname. The buffer must be large enough to 
contain the longest pathname that could be returned. 

The contents of the miscellaneous field determines which name Is 
the next name. When the field contains 1, the operation returns 
the preceding name In alphabetical order. When the field 
contains 0, the operation returns the succeeding name. 


19.5.4 Purge Names (Subopcode >06). 

The Purge Names operation (subopcode >06) deletes related logical 
names from the set of logical names available to the task. The 
calling task supplies a name containing N characters. A name Is 
deleted If any of the following statements Is true of that name : 

* The name contains N characters, and these characters are 
equal to those of the supplied name. 

* The name contains N characters, all but the last are 
equal to those of the supplied name, and the last 
character Is greater than the last character of the 
supplied name . 

* The name contains more than N characters and the first N 
characters are equal to those of the supplied name. 

* The name contains more than N characters, the first N-1 
characters are equal to the corresponding characters of 
the supplied name, and the Nth character Is greater than 
the Nth character of the supplied name. 

No name that Is shorter than the supplied name Is deleted. 
Otherwise, the length of the name does not determine whether or 
not It Is deleted. The pathname of the name Is Ignored In 
selecting a name for deletion. 

The following fields of the supervisor call block apply; 

* Opcode - >43 

* Return code 

* Subopcode - >06 
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* Flags 

* Address of name 

When the name type flag In the flags byte Is set to zero, the 
operation expects the name to be a synonym, and purges the 
synonyms available to the calling task. 

The address of name field must contain the address of a buffer 
that contains the length of a name In the first byte, and the 
characters of that logical name in succeeding bytes. 

As an example, the following logical names are defined for a 
t ask : 

INFILE OUTFILE 

ABCD ABODE 

If a purge names operation were performed supplying name IN, 
names INFILE and INPUT would be deleted. If the name supplied 
were INF, the same two names would be deleted. If ABODE were 
supplied as a name, names ABODE and ABODEF would be deleted. 


INPUT 

ABODEF 


19.5.5 Enter New Stage (Subopcode >07). 

When the Enter New Stage operation (subopcode 07) Is issued, the 
calling task becomes the first and only task In a new stage* 
Tasks bid by the calling task also execute In the new stage. 
Logical names and synonyms available to the task prior to 
entering the new stage become the logical names and synonyms for 
the new stage. Additions and changes made by tasks In the stage 
apply only to the stage. 

The following fields of the supervisor call block apply: 

* Opcode - >43 

* Return code 

* Subopcode - >07 


19.5.6 Return to Previous Stage (Subopcode >08). 

Only a task that has created a new stage may return to the 
previous stage (the stage It belonged to before creating the new 
stage). The Return to Previous Stage operation (subopcode >08) 
returns the calling task to the previous stage, optionally taking 
a set of synonym names. 

When other tasks remain In the current stage, or when descendant 
stages remain, the calling task returns to the previous stage. 
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and the current stage remains. When the calling task Is the only 
task In the current stage and no descendant stages exist, the 
calling task returns to the previous stage and the current stage 
Is deleted • 

The descendant error list Is the mechanism for retaining the 
values of error synonyms $$CC, $$ES, $$MN, $$FN, and $$VT when a 

stage Is deleted. When a descendant stage Is deleted, and that 
stage has error synonym $$CC In the synonym table, a descendant 
error list entry Is built. The entry becomes the first entry In 
the descendant error list for the stage> or an additional entry 
In an existing list. 

The descendant error list consists of a byte that contains the 
length of the list, followed by the entries of the list. Each 
entry consists of the following: 

* The value of error synonym $$CC, preceded by a byte that 

contains the length of the value. 

* The value of error synonym $$ES, preceded by a byte that 

contains the length of the value, or zero If no value 

has been assigned. 

* The value of error synonym $$MN, preceded by a byte that 
contains the length of the value, or zero If no value 
has been assigned. 

* The value of error synonym $$FN, preceded by a byte that 

contains the length of the value, or zero If no value 

has been assigned. 

* The value of error synonym $$VT, preceded by a byte that 
contains the length of the value, or zero If no value 
has been assigned. 

When a stage Is deleted, the following actions occur: 

* Add the entries. If any. In the descendent error list of 
the terminating stage to the list of the previous stage. 

* When error synonym $$CC has been assigned for the 
terminating stage, place a descendant error list entry 
In the list of the previous stage. 

* Delete synonyms and logical names defined for the 
terminating stage. 

The following fields of the supervisor call block apply: 

* Op code — >43 

* Return code 
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* Suboptode->08 

* Address of name 

The address of name field contains the address of a buffer, or 
zero. When the field contains zero, no synonym names are 
returned. When the field contains an address, the address Is the 
address of a synonym buffer. The buffer contains a byte that 
contains the length of the synonym list, followed by the names of 
the synonyms In the list. Each synonym is preceded by a byte 
that contains the length of the synonym. The synonym buffer Is 
returned to the previous stage, and the Name Manager adds the 
synonyms to those of the previous stage, obtaining the values 
from the synonym segment. 


19.5.7 Return Next Error Entry '(Subopcode >09). 

The Return Next Error Entry operation (subopcode >09) obtains the 
first entry on the descendant error list previously described. 
The operation also deletes the entry. This operation Is normally 
performed by system tasks that process errors. 

The following fields of the supervisor call block apply; 

* Opcode - >43 

* Return code 

* Subopcode - >09 

* Address of value 

The address of value field contains the address of a buffer in 
which the operation returns a descendant error list entry. The 
first byte of the buffer contains the length of the buffer. When 
there Is no entry, the operation returns zero In the first byte 
of the buffer. Otherwise, the operation returns the length of 
the entry In the first byte of the buffer, followed by the 
characters of the entry. 


19.5.8 Determine Segment Size (Subopcode >0A). 

The Determine Segment Size operation (subopcode >0A) returns the 
size required for a segment large enough to contain all the 
logical names or synonyms available to the calling task. 

The following fields of the supervisor call block apply: 

* Opcode - >43 

* Return code 
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* Subopcode - >0A 

* Flags 

* Miscellaneous 

The name type flag In the flags field Is set to 0 to obtain the 
size for a synonym segment, or to 1 to obtain the size for a 
logical name segment. 

The size. In bytes, required for the specified name segment Is 
returned In the miscellaneous field. 


19.5.9 Copy Names to New Segment (Subopcode >0B) . 

The Copy Names to New Segment operation (subopcode >0B) copies 
the logical names or synonyms available to the calling task to a 
specified segment. The segment size should be obtained using the 
Determine Segment Size operation, and a segment of that size 
should be allocated. The segment should be a memory-based 
segment with the share-protect and reusable attributes. 

The following fields of the supervisor call block apply: 

* Opcode - >43 

* Return code 

* Subopcode - >0B 

* Flags 

* Miscellaneous 

The name type flag In the flags field Is set to 0 to copy a 
synonym segment, or to 1 to copy a logical name segment. The 
segment ID of the allocated segment Is placed In the 
miscellaneous field. 


19.5.10 Creating an Empty Name Segment (Subopcode >0D). 

The Create Empty Name Segment operation (subopcode >0D) creates 
an empty logical name segment. The following fields of the 
supervisor call block apply: 

* Opcode - >43 

* Return Code 

* Subopcode - >0D 
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* Flags 

* Segment size 

* Segment ID 

The only flag examined Is the global flag. This operation can be 
performed only once. This Is done by the system restart task. 

The address of name field, address of value field, and address of 
parameter must be zero. 

The segment size Is a value In bytes, specifying the Initial size 
of the segment. The run ID of the segment Is returned. 

The following Is an example of coding for a supervisor call block 
for a Create Empty Name Segment operation and for the required 
buffers : 


EVEN CREATE EMPTY NAME SEGMENT 

CEMNAM BYTE >43 
CENS BYTE 0 

BYTE >0D 
BYTE >00 
DATA 0 
DATA 0 
DATA 0 
DATA >400 
CID DATA 0 


19.5.11 Saving a Name Segment (Subopcode >0E). 

The Save Name Segment operation (subopcode >0E) saves a logical 
name segment to a disk file. The following fields of the 
supervisor call block apply: 

* Opcode - >43 

* Return Code 

* Subopcode - >0E 

* Flags 

* Address of name 

* Segment ID 

The only flags examined are the global flag and the run ID flag. 
The global flag set to one Indicates that the global names are to 
be saved. The run ID flag Indicates that the segment to save Is 
passed In the call block In the run ID field. If no flags are 
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set the job local synonyms are saved. 

The address of name field must contain the address of a buffer 

that contains the length of the name In the first byte and the 

characters of the logical name definition In succeeding bytes. 

Names can be saved on any disk on any system. The one 

restriction Is job-local logical names may not be used to specify 
the pathname . 

The address of value field, and address of parameter list field 
mu s t be zero. 

If the user flag for global operation Is set to one, the global 
names will be written, otherwise the job local names will be 
written, unless the run ID flag Is set to one. In which case the 
segment passed In the run ID field will be saved. 

The following Is an example of coding for a supervisor call block 
for a Save Name Segment operation and for the required buffers: 

EVEN SAVE NAME SEGMENT 

SAVNAM BYTE >43 
SVNS BYTE 0 

BYTE >0E 
BYTE >00 
DATA LNME 
DATA 0 
DATA 0 

LNME BYTE 11 

TEXT ' . DISK.FILE2' 


19.6 MODIFY BTA OR JCA SIZE 


The Modify BTA or JCA Size SVC (>4A) Is of the following format: 

Align on word boundary 
Software privileged 


Offset 

00 

*- 

1 

4A 

+ 

1 <Return Code> 

02 

1 

Subopcode 

1 Reserved 

04 

"T — 

1 

Number of 

Beets Requested 

06 

“r~ 

1 

* - 

Segment Run 

ID ( subopcode 3 ) 
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Byte 2 - subopcodes : 

0 - Allocate more static buffer 

1 - Deallocate static buffer 

2 - Find amount of static buffer currently In use 

3 “ Expand the segment ID specified 

Subopcode 0 of this SVC is used to expand the BTA used by the I/O 
subsystem. Memory is taken from dynamic user memory to expand 
the BTA as one contiguous block at the end of system memory. 

Subopcode 1 is used to release memory (number of beets specified) 
from the BTA and return it to dynamic user memory. Subopcode 2 
retrieves the number of beets of BTA currently in use. Subopcode 
3 is used to expand the size of a JCA segment that is currently 
In memory but Is not a memory-resident segment. The segment Is 
expanded by the amount specified In bytes 4 and 5 of the call 
block. The new size must be less than >800 beets and It must be 
less than the maximum JCA size. 


19.7 HALT/RESUME TASK 


The Halt/Resume Task SVC Is of the following format: 

Align on word boundary 
Software privileged 


Offset 

00 

*- 

1 


4B 

1 

<Return Code> 

02 

“1““ 

1 

Task 

Run ID 

1 

Task Station ID 

04 

1 

<Task 

S t a t e > 

I 

Sub-Opcode 

06 

“T" 

1 

* . 


Reserved 


Byte 5 - Subopcodes: 

0 - Halt task 

1 - Resume task 


The Halt/Resume Task SVC is used by the SCI Debugger to halt a 
task before showing debugging information and to resume the task 
once that Information has been displayed to the user. 

The program management routine PMHALT executes this SVC at XOP 
level. If the station ID supplied is nonzero, the routine first 
checks to be sure a task with the supplied run-time ID is running 
at that station. If no such task Is running, an error code of 1 
1 s returned . 


2270512-9701 


19-51 


Special SVCs 



DNOS System Design Document 


If a task Is found, the current state of the task Is returned In 
the byte reserved for the task state. If the subopcode requested 
Is Halt, PMHALT sets the halt bit in the TSB flags TSBFL2 • If 
the current task state is active, PMHALT calls the deactivate 
routine and sets the task state to 6 (unconditional wait). 

If the subopcode requested is Resume, PMHALT clears all of the 
debug (breakpoint) bits and the halt bit in the TSB flags TSBFL2 . 
If the task is in state 6, PMHALT calls NFPACT to place the task 
on the active queue. In other cases, it exits after setting the 
TSB flags. 


19.8 EXPAND JCA 


The job communication area (JCA), one of the data structures 
maintained for each job by the system, is expandable. The system 
uses the Expand JCA operation to provide more space for the JCA 
as required. This operation is not available to user tasks. 

Subopcode >08 specifies the Expand JCA operation. Only the first 
16 bytes of the supervisor call block apply. The specific fields 
are : 

* Opcode 

* Return code 

* Subopcode 

* Job run ID 

The job run ID is supplied by the system task. 

The following is an example of coding for a supervisor call block 
for an Expand JCA operation: 

EVEN EXPAND THE JCA FOR JOB >4F. 

EXPJCA BYTE >48 
XJERR BYTE 0 

BYTE >08 
BYTE 0 
DATA 0 
DATA >4F 
DATA 0,0, 0,0 
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SECTION 20 

LINKING INFORMATION FOR DNOS 


20.1 OVERVIEW 

Linking the portions of DNOS Involves standard use of the Link 
Editor for assembly language and for Pascal modules. Link 
control files for the nonconf 1 gurabl e portions of DNOS are found 
In the directories DSC . LINK. SYSTEM and DSC . LINK. UTIL ITY . 
Configurable portions of DNOS are determined during system 
generation and appropriate selections are Included in the link 
control files DMLINK, lOULINK, and SYSLINK. 

Conventions used in building the link control files are simple. 
Each file makes use of the NOPAGE and ERROR options of the Link 
Editor. Wherever possible LIBRARY and INCLUDE statements are 
used to keep the files short and easy to read. 

Tasks written In assembly language generally Include only their 
own object library. If they make use of S$ routines, they 
include the library VOLOB J . SCI 990 . S $0B JECT . In addition to the 
S$ library, tasks written In Pascal have three run-time libraries 
available to them. These are located via the PASCAL synonym In 
the libraries PASCAL .MINOBJ , PASCAL . LUNOBJ, and PASCAL. OBJ. The 
MINOBJ library Is a minimum size library for a non-debug 
environment. The LUNOBJ library Is for a non-SCI environment and 
includes routines to support I/O by LUNO. The OBJ library Is the 
run-time collection for either environment. 

Pascal tasks which make use of standard initialization must use 
the statement INCLUDE (R$TASKDP) as the first Item In the 
link control stream after the TASK or PHASE 0 statement. When 
linking a Pascal task which has a single procedure segment, the 
PROCEDURE declaration must be followed by INCLUDE (R$PR0CDP). 
If a procedure Is shared by more than one task, a SEARCH command 
must appear at the end of the include statements for the 
procedure, and an ALLOCATE command must Immediately follow the 
R$TASKDP Include statement. This is to ensure that all the 
shareable run-time routines are included in the procedure 
segment . 

The directory DSC . LINK. SYSTEM includes link control files for 
each of the DNOS system tasks. The directory DSC . LINK. UTILITY 
Includes link control files for each of the utility tasks. The 
directory DSC. LINK. DSR has link control files for DSRs , and the 
directory DSC . LINK. DNOSPROG has link control files for the 
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programs used to build DNOS. Llnkmaps for each of these are 
found In the directories VOLLST . LINKMAP . SYSTEM and 
VOLLST. LINKMAP. UTILITY , where VOLLST Is the volume to which 
listings are written during a build of DNOS. The .SYSTEM 
directory Includes llnkmaps for each of the DNOS system tasks; 
the .UTILITY subdirectory for each of the utility tasks which 
supports SCI commands. To find the appropriate llnkmap for a 
given SCI command, check the task name being bid by the command 
procedure and search for that name as a llnkmap file name In the 
DSC. LINKMAP. UTILITY directory. 

The paragraphs below describe the linking Information from link 
control files for a system task written In assembly language, a 
system task written In Pascal, a DSR, and the system nucleus 
(seed). Examples of link control files generated during system 
generation are also presented. 


20.2 LINKING A SYSTEM TASK 


The link control stream for a system task must provide for the 
task to be loaded at address >C000. This requires use of the 
PHASE command with the base option set to >C000. The starting 
address of >C000 allows the task address space to Include the 
system root and a JCA prior to the task code. All system tasks 
are linked with the procedure DUMROOT, which enables access to 
the system root. DUMROOT Is built from the Interrupt tables, the 
system seed, and the common blocks Initialized by sysgen. 

Appropriate libraries must be specified If subroutine support 
modules are Included. The link control stream for the IPL task 
Is shown below. It Includes support routines from the DISKMGR 
and UTCOMN directories as well as the set of IPL object modules. 
The synonym VOLOBJ Is used throughout this section to represent 
the volume on which the operating system object directories 
reside . 


NOPAGE 

ERROR 

FORMAT IMAGE, REPLACE 


LIBRARY 
LIBRARY 
LIBRARY 
PROCEDURE DUMROOT 
DUMMY 
INCLUDE 


VOLOBJ. DISKMGR. OBJECT 
VOLOBJ. UTCOMN. OBJECT 
VOLOBJ.NAMMGR .OB JECT 


V0L0BJ.S$SGU$ .DUMROOT 
PHASE 0, IPL, PROG >C000 

INCLUDE VOLOB J. LOADERS .OBJECT .SLIPL 

INCLUDE VOLOB J. LOADERS .OB JECT. SLCRSH 

INCLUDE VOLOBJ. LOADERS .OBJECT .SLDINT 

INCLUDE VOLOBJ. LOADERS .OBJECT . SLDIO 

INCLUDE VOLOBJ . LOADERS .OBJECT.SLDISP 
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INCLUDE VOLO B J. LOADERS .OBJECT. SLD SR 

INCLUDE V OLO BJ. PERFORM. OBJECT .PFWC SO 

INCLUDE VOLOBJ.PERFORM.MOBJECT .PFDWCS 

INCLUDE VOLOBJ.LOADERS .OBJECT .SLFDB 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLINIT 

INCLUDE VOLOBJ.LOADERS .OBJECT .S LI V 

INCLUDE VOLOBJ.LOADERS .OBJECT .SLJCA 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLLMOD 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLOPEN 

INCLUDE VOLOBJ.LOADERS .OBJECT .SLPFIO 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLTABL 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLTASK 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLVRFY 

INCLUDE VOLOBJ.LOADERS .OBJECT. SLWCS 

INCLUDE (UTPTCH) 

INCLUDE (UTVERS) 

INCLUDE VOLOBJ.LOADERS .OB JECT . SLEND 

END 


The following link control stream links the log formatter task, 
LGFORM. It is written in Pascal and requires run time support, 
S$ routine support. Interface with assembly language routines 
using the PASASM directory, and routines from the UTCOMN 
directory. The file specifies the Pascal base routine R$TASKDP 
as the first portion of the LGFORM task and Includes required 
modules from the various directories as needed. 

NOPAGE 

NOSYMT 

LIBRARY VOLOBJ.LOG.OBJEGT 

LIBRARY PASCAL.MINOBJ, PASCAL.LUNOBJ, PASCAL.OB J 

LIBRARY VOLOBJ.UTCOMN.OBJEGT 

LIBRARY VOLOBJ. PASASM. OBJECT 

PROCEDURE DUMROOT 

DUMMY 

INCLUDE VOLOBJ. S$SGU$. DUMROOT 

PHASE 0 , LGFORM, PROG >C000 ; SYSTEM LOG FORMATTER TASK 

INCLUDE (R$TASKDP) 

INCLUDE (LGFORM) 

INCLUDE (LGDATA) 

INCLUDE (UTR$ST) 

INCLUDE (UTPTCH) 

END 


20.3 LINKING A DSR 

A DSR must be linked as a system task. Including the relevant 
source code modules written by the user as well as the 
appropriate modules from VOLOBJ . lOMGR . OB JECT to access support 
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subroutines. The section on writing DSRs lists the location and 
function of each of the support subroutines. The example DSR 
link given below Is for the 911 VDT and Includes the modules 
which provide keyboard support (lOKB) and end of record 
processing (lONRCD), 

NOPAGE 

ERROR 

PROCEDURE DUMROOT 
DUMMY 

INCLUDE VOLOBJ.S$SGU$. DUMROOT 

PHASE 0,DSR911 ,PROG >C000 
INCLUDE VOLOBJ.DEVDSR. OBJECT .DSR91 1 

INCLUDE VOLOBJ. lOMGR.OBJECT.IONRCD 

INCLUDE VOLOBJ. lOMGR. OBJECT. lOKB 

INCLUDE VOLOBJ. UTCOMN. OBJECT .UTPTCH 

INCLUDE VOLOBJ.DEVDSR. OBJECT . PWRFY 

END 


20.4 LINKING THE DNOS SEED 

The common nucleus functions are linked Into a task named SEED 
using the link control file In DSC . LINK . SYSTEM. SEED , Modules are 
Included If they must be used by operating system code In any of 
a number of mapping configurations. The SEED Is Included as part 
of the system root when the system Is generated. The following 
Is an example of the link control file for the SEED. 

ERROR 
PARTIAL 
TASK SEED 

INCLUDE VOLOB J. NUCLEUS .OB JECT .NFMAT 

INCLUDE VOLOBJ. lOMGR. OBJECT. lOBM 

INCLUDE VOLOBJ. I OMGR. OB JECT . lODBGN 

INCLUDE VOLOBJ. IPC. OBJECT. IPCPR 

INCLUDE VOLOBJ. IPC. OBJECT. IPCXFR 

INCLUDE VOLOBJ.LOG. OBJECT. LGQACC 

INCLUDE VOLOBJ. LOG. OBJECT. LGQBLK 

INCLUDE VOLO B J. NUCLEUS .OBJECT .NFACTL 

INCLUDE VOLOBJ. NUCLEUS .OBJECT .NFACTQ 

INCLUDE VOLOBJ. NUCLEUS .OBJECT .NFATOL 

INCLUDE VOLOB J. NUCLEUS .OBJECT .NFCLOK 

INCLUDE VOLOBJ .NUCLEUS .OB JECT .NF COPY 

INCLUDE VOLO B J. NUCL EUS .OB JECT. NFCRSH 

INCLUDE VOLO BJ. NUCL EUS .OBJECT .NFDACT 

INCLUDE VOLO BJ. NUCL EUS .OBJECT .NFCE OR 

INCLUDE VOLO BJ. NUCL EUS. OB JECT .NFDEF 

INCLUDE VOLOBJ. NUCL EUS .OBJECT .NFDLNK 

INCLUDE VOLOBJ .NUCLEUS .OBJECT .NFDLOV 

INCLUDE VOLO BJ. NUCLEUS .OB JECT. NFDOOR 
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INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 


VOLO B J. NUCLEUS. OB JECT.NFDOVB 
VOLO BJ. NUCLEUS. OBJECT .NED Q1 
VOLO BJ. NUCLEUS .OB JECT.NFDQH 
VOLO BJ. NUCLEUS .OBJECT .NFDTOL 
VOLO B J. NUCLEUS. OB JECT .NFDTSK 
VOLO BJ. NUCLEUS .OB JECT .NFDWOM 
VOLO B J. NUCLEUS. OB JECT .NFDWOT 
VOLO BJ. NUCLEUS .OBJECT .NFENAB 
VOLOBJ. NUCLEUS. OB JECT.NFEOR 
VOLO BJ. NUCLEUS .OBJECT .NFI NT 2 
VOLOBJ. NUCLEUS .OBJECT .NFLOVB 
VOLO BJ. NUCLEUS. OB JECT .NFLWCS 
VOLOBJ. NUCLEUS .OBJECT .NFMAPO 
VOLOBJ. NUCLEUS .OBJECT .NFPACT 
VOLO BJ. NUCLEUS .OBJECT .NFPOP 
VOLOB J. NUCLEUS. OB JECT .NFPSH 
VOLO B J. NU CL EUS .OBJECT .NFPWOT 
VOLO BJ. NUCLEUS .OBJECT .NFPWUP 
VOLOBJ. NUCLEUS .OBJECT .NFQERR 
VOLO B J. NUCLEUS .OBJECT .NFQOVB 
VOLOB J. NUCLEUS .OB JECT.NFQUEl 
VOLOB J. NUCLEUS. OB JE CT .NFQUEH 
VOLOBJ. NUCLEUS .OBJECT .NFSRTN 
VOLOBJ. NUCLEUS. OB JECT .NFTBDO 
VOLOBJ.NUCLEUS .OBJECT'.NFTERM 
VOLO BJ. NUCLEUS .OBJECT .NFTMGR 
VOLOBJ.NUCLEUS .OB JECT .NFTRTN 
VOLOBJ.NUCLEUS .OBJECT .NFWAKE 
VOLO BJ. NUCLEUS. OB JECT .NFWOMJ 
VOLOBJ.NUCLEUS.OBJECT .NFWOML 
VOLOBJ.NUCLEUS .OBJECT .NFWOTL 
VOLOBJ.NUCLEUS .OB JECT. NFXOPS 
VOLOBJ.NAMMGR.OBJECT .NMTRAN 
VOLOBJ. PROGMGR. OB JECT. PMMPR I 
VOLOBJ. PROGMGR. OB JE CT .PMTSCH 
VOLOBJ.REQPROC. OBJECT.RPDQl 
VOLOB J.REQP ROC. OBJECT .RPMAP 2 
VOLOBJ.REQPROC. OB JECT. RPPRCK 
VOLOBJ.REQPROC. OBJECT .RPSGCK 
VOLOBJ.SEGMGR.OBJECT.SMBLDS 
VOLOBJ.SEGMGR.OBJECT .SMBUFF 
VOLOBJ.SEGMGR.OBJECT. SMCHUC 
VOLOBJ.SEGMGR.OBJECT .SMCS GO 
VOLOBJ.SEGMGR.OB JECT. SMDSGB 
VOLOBJ.SEGMGR.OBJECT.SMDSSB 
VOLOB J. SEGMGR. OB JECT. SMF SID 
VOLOBJ.SEGMGR.OBJECT .SMLOAD 
VOLOBJ.SEGMGR.OBJECT . SMMJCA 
VOLOBJ.SEGMGR.OBJECT.SMMSEG 
VOLOBJ. SEGMGR. OB JECT. SMMTBL 
VOLOBJ. SEGMGR. OB JECT .SMRMVE 
VOLOBJ .SEGMGR. OB JECT .SMS RCH 
VOLOBJ.SEGMGR.OBJECT . SMUNLD 
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END 


20.5 LINK CONTROL FILES BUILT DURING SYSTEM GENERATION 

Based on the options specified during system generation, a set of 
link control files Is built as SYSLINK, lOULINK, and DMLINK. 
These files are In the directory . S $ SGU$ . < sys t em naine> for the 
system you generate. SYSLINK Is the link of the major portions 
of the operating system and varies according to user 
specification of the following: 

* System SVC options 

* User SVCs 

* File Security 

* KIF support 

The lOULINK file varies depending on whether or not security Is 
Included. 

The DMLINK file Is the link control file for the disk manager 
task. 
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SECTION 21 

DNOS SOURCE DISK STRUCTURE 


21.1 DIRECTORY STRUCTURE 

The following Is a directory listing of the dlrectorle.s on a DNOS 
source disk. Throughout this section, DSC Is used as a synonym 
for the volume on which DNOS source code resides. 


AGTASK 

ALN 

ANALZ 

ASP 

AUI 

AXREF 

BATCH 

BDD 

BEMF 

BLDPROCS 

BMF 

CB 

CC 

CD 

CKD 

CKR 

COM 

CONDASM 

CONDPASC 

CP 

CPI 

CRV 

CSK 

CSM 

CV 

CVD 

DCOPY 

DD 

DEBUG 

DEBUGGER 

DEVDSR 

DIOU 

DISKMGR 

DNCMS 
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DSCBLD 

DXDP 

EDITOR 

FILEMGR 

IBMUTL 

IDS 

IDT 

IFSVC 

lOMGR 

lOU 

IPC 

JENED 

JOBMGR 

KIFMGR 

LAGFR 

LD 

LINK 

LINKER 

LLR 

LOADERS 

LOG 

LOGON 

LS 

LSC 

LTS 

MACROS 

MAD 

MAILBOX 

MCDT 

MD 

MESSAGES 

MKL 

MLP 

MPC 

MPF 

MPI 

MRF 

MS 

MSAR 

MTE 

MVI 

NAMMGR 

NUCLEUS 

0 $ 

OPERATOR 

PASASM 

PATCH 

PERFORM 

PF 

PICT 

PROGMGR 

RAL 

REQPROC 
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RESOLVE 

RESTART 

RVI 

RWCRU 

S$ 

S$SGU$ 

SCI990 

SCS 

SCU 

SD 

SDSMAC 

SECURITY 

SEGMGR 

SEM 

SIS 

SJS 

SMMAP 

SMS 

SND 

SOS 

SPOOLER 

SRFI 

SVS 

SYSJEN 

SYSOVLY 

TEMPLATE 

TFTPC 

TIGRESS 

TINFO 

TPCALANS 

TPDISC 

TPLHPC 

TPMHPC 

UTCOMN 

XBJ 

XJM 

XOI 


The following flies also appear on the DNOS source disk: 

DNOSPROG 

TAPEOBJ 


21.2 COMPONENTS USED IN BUILDING DNOS 

Building DNOS Involves creating several batch streams as well as 
using some batch streams which already exist In the 
DSC . BATCH . BUILD directory. The batch streams which are created 
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during the build are a product of the Create Batch (CB) utility 
working with the batch stream templates In the DSC . BATCH . CB INPUT 
directory. Any process (batch stream) which needs to be 
performed on a directory of files Is generated by CB. 

All of the files necessary for building DNOS reside In the 
DSC. BATCH directory. The components of this directory are 
described In the paragraphs which follow. 

ASSEMBLE 

This Is a directory of batch streams, each of which 
assembles a directory of DNOS source code. In general, a 
DNOS code directory comprises the modules of a subsystem or 
single utility. This directory Is built using CB and exists 
only after a DNOS build has been done. Executing the batch 
stream DSC . BATCH .ASSEMBLE .ALL causes all of the batch 
streams in this directory to be executed. 


BUILD 

This directory consists of the batch streams to build DNOS 
as well as those used to build the DNOS SCI menus and SCI 
command procedures. Its files are described further In 
other portions of this section. 

CBINPUT 

When CB Is used to create some of the DNOS build batch 
streams, templates for those batch streams are found In this 
directory. The templates are described further In other 
portions of this section. 

COMPILE 

Like the ASSEMBLE directory, the COMPILE directory Is built 
using CB. This directory Is composed of the batch streams 
which compile all of the Pascal source In DNOS. The COMPILE 
directory exists only after a DNOS build has been done. 
Executing the batch stream D SC . BATCH . COMPI LE . ALL causes all 
of the compilation batch streams In this directory to be 
executed . 


LINK 

This directory contains batch streams to link the whole 
system. It is built using CB and exists only after a DNOS 
build has been done. Executing the batch stream 
DSC . BATCH .LINK. ALL links the whole system. 


PICT 

This directory consists of two batch streams, one of which 
generates PTABLE templates for the ATABLE directory In 
DSC. TEMPLATE and one of which generates PTABLE templates for 
the COMMON directory. This directory exists only after a 
DNOS build has been done. 

TRANSLIT 
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This directory is composed of a set of batch streams which 
transliterate the source modules of the LINKER directory. 
It exists only after a DNOS build has been done. Executing 
the batch stream DSC . BATCH .TRANSLIT .ALL causes all of the 
transliteration batch streams in this directory to be 
executed . 

The Create Batch (CB) utility processes an input directory, 
applying to each element of the directory a specified batch 
stream template. It generates an output batch stream to a file 
specified when the CB command is issued. The command prompts are 
documented in the DNOS System Command Interpreter (SCI) 
Reference Manual. 


Files within the DSC . BATCH . CB INPUT directory are used as batch 
template files for CB when creating many of the DNOS build batch 
streams. These CBINPUT files are described in the paragraphs 
which follow, 

ALL 

This template is used to create a batch stream which 
executes a directory of batch streams. It is used in the 
DNOS build process to create the DSC . BATCH , <D> . ALL where <D> 
is ASSEMBLE, AXREF, COMPILE, DELETE, or PICT, depending on 
which is needed . 

ASSEMBLE 

This template is used to create the batch stream to assemble 
all the modules in one DNOS source directory. 


AXREF 

This template is used to create a batch stream to produce a 
cross-reference listing for a given directory of DNOS 
listings. 


CB 

This template is used to create the DSC . BATCH , BUILD ,<? > 
batch stream where <?> is one of ASSEMBLE, AXREFS , COMPILE, 
DELETE, PICT, and TRANSLIT. Each of these batch streams 
creates the directory of batch streams to process each 
appropriate directory of DNOS. For example, the batch 
stream e D SC . BATCH . BUILD . ASSEMBLE built using CB is a batch 
stream which creates the assembly batch streams (using CB) 
for each of the source directories of DNOS, This set of 
assembly batch streams resides in DSC • BATCH .ASSEMBLE . the 
whole DNOS directory using one of the other CBINPUT 
templates. For example, it is used to build the directory 
of assembly batch streams using the ASSEMBLE template. 

COMPILE 

This template is used to create the batch streams to compile 
all of the Pascal source modules in one of the DNOS 
directories . 
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DELETE 

This template Is used to create the batch stream to delete 
the old, outdated object and listing directories for the 
corresponding DNOS source directory. 

FORTRN78 

This template is used to create a batch stream to compile 
all of the FORTRAN source modules In one of the DNOS 
dl rectories • 


LINK 

This template Is used to build a batch stream to link a part 
of DNOS. 

PICT 

This template Is used to create the batch stream to build 
the PTABLE template directory for the appropriate ATABLE or 
COMMON template directory. 

TRANSLIT 

This template Is used to create the batch stream to 

transliterate the modules In a given DNOS source directory. 

The only directory for which this Is needed Is the LINKER 

source directory. 

The files In the D SC . BATCH . BUILD directory are listed In Table 
21-1. The purpose of each file Is Indicated. Those created 
during the build process exist only after a DNOS build has been 
done; these are Indicated by a star In the second column of the 
table. All those not created during a build are further 

explained In the paragraphs which detail the steps In doing a 
DNOS build. 


Table 21-1 DNOS Batch Stream Files 


File Name 


Purpose 


ASSEMBLE * 
AXREFS * 


BATCH 

BSD2 

BST2 

BST3 

BST4 

CDl 400 

COMPILE * 

DELETE * 


Creates the DSC . BATCH . ASSEMBLE directory 
of batch streams to assemble all source 
Creates the DSC . BATCH . AXREF directory of 
batch streams to generate cross-reference 
lists 

Creates batch streams 

Used for building DNOS from floppy disks 
Used for building DNOS from tape 
Used for building DNOS from tape 
Used for building DNOS from tape 
Builds a CD1400 system disk 

Creates the DSC . BATCH . COMPI LE directory of 
batch streams to compile all source 
Creates the DSC . BATCH . DELETE directory of 
batch streams to delete object and 
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DNOS 

DNOSPROG 

DS50 

DS200 

DS300 

DS80 

LNKDNOS 

MENU 

MESSAGEl 

MESSAGE2 


OBJECT 


OBJKIT 

PICT 


PROCO 

PROC2 

PROC4 

PROC6 

PROCSYS 

S$LANG 

S$OBJECT 

S$SECURE 


S$UTIL 


SRCKIT 

TAPE 

TRANSLIT 
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Builds the DNOS system disk to be shipped 
Builds a program file with DXlO versions 
of DNOS utilities needed to build DNOS 
Builds DS50 system disk 
Builds DS200 system disk 
Builds DS300 system disk 
Builds DS80 system disk 
Builds the linkable parts needed to 
generate DNOS 
Builds the DNOS SCI menus 
Builds the source directories and the 
DNOS usable 

directories of short and long form 
messages as well as the batch streams to 
build DNOS SCI command procedures 
Builds the DNOS object from the source by 
executing the ASSEMBLE, COMPILE, and 
TRANSLIT batch streams 
Builds a shlppable DNOS object disk from 
DNOS object libraries 
Creates the PTABLE templates from the 
corresponding ATABLE and COMMON 
templates 

Creates the privilege level 0 DNOS SCI 
procedures 

Creates the privilege level 2 DNOS SCI 
procedures 

Creates the privilege level 4 DNOS SCI 
procedures 

Creates the privilege level 6 DNOS SCI 
procedures 

Creates the procedures for . S SY STEM . S $ CMDS 
Creates the .S$LANG program file and 

Installs the Assembler and Link Editor 
Builds the directory . SC I 990 . S $0B JE CT 
Performs the task, procedure, and overlay 
Installations to build the .SSECURE 
program file. 

Performs the task, procedure, and overlay 
Installations to build the .S$UTIL 
program file. 

Builds from source kit 
Builds DNOS onto tape 

Creates the DSC . BATCH . TRANSLIT directory 
of batch streams to transliterate DNOS 
source directories 
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21.3 THE PROCEDURE FOR BUILDING DNOS 

The DNOS source disk Includes the set of DNOS source modules, a 
program file of special tasks to build DNOS, and a command 
procedure library with special commands to build DNOS, The 
process must be executed using DNOS, following the Instructions 
In the DNOS Source Installation Document. 


21.4 DNOS PROGRAM FILES 


Table 21-2 and Table 21-3 are maps of the DNOS utility and system 
program files, respectively. The following flags are used In 
both tables : 

Flags In Program File Maps 


FLAG DEFINITIONS 

PRI - PRIORITY 

S - SYSTEM 

P - PRIVILEGED 

M - MEMORY RESIDENT 

R - REPLICATABLE 

RU - REUSABLE 

CP - COPYABLE 

E - EXECUTE PROTECTED 

SP - SOFTWARE PRIVILEGED 


D - DELETE PROTECTED 

U - UPDATABLE 

0 - OVERFLOW 

c - writable control store 

W - WRITE PROTECTED 

SH - SHARABLE 

MAP - RELOCATION BIT MAP PRESENT 
OVLY- OVERLAY LINK 
B - BYPASS SECURITY 


Pl/S - PROCEDURE 1 IS ON SAME PROGRAM FILE AS TASK 
P2/S - PROCEDURE 2 IS ON SAME PROGRAM FILE AS TASK 
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Table 21-2 Map of Utility Program File 
FILE MAP OF .S$UTIL 

TODAY IS 13:34:26 TUESDAY, SEPTEMBER 27, 1983. 

TASK SEGMENTS: MAX POSSIBLE =176 


ID 

NAME 

LENGTH 

LOAD 

PRI 

S 

p 

M R D 

U RU CP E 0 C SP B 

OVLY 

Pl/S P2/S 

DATE 

01 

SCI990 

2056 

7FA0 

1 



R 



02/Y 03/Y 

8/19/83 

02 

TINFO 

30B8 

7FA0 

4 


p 

R 



02/Y 03/Y 

8/19/83 

03 

MS 

0C28 

lAOO 

4 



R 



02/Y 

8/19/83 

04 

PMTERM 

09 CA 

COOO 

0 

S 

p 


SP 


01/Y 

8/19/83 

05 

lOTBID 

0132 

COOO 

0 

S 

p 

M 

SP 


01 /Y 

8/19/83 

06 

IPC 

1B76 

COOO 

0 

S 

p 


SP 


01/Y 

8/19/83 

07 

MAILBOX 

24AA 

0000 

4 







8/19/83 

08 

CKD 

2096 

lAOO 

4 


p 

R 

SP 


02/Y 

8/19/83 

09 

MPC 

1F96 

lAOO 

4 



R 



02/Y 

8/19/83 

OA 

LOGON 

2568 

COOO 

0 

S 

p 

R 

SP 


01/y' 

8/19/83 

OB 

XPD 

ODEA 

COOO 

1 

S 

p 

R 



01/Y 

8/19/83 

OC 

SMM 

OBEC 

COOO 

1 

S 

p 

R 



01/Y 

8/19/83 

OD 

DEBUGGER 

70E8 

lAOO 

4 


p 

R 

SP 


02/Y 

8/19/83 

OE 

EDITOR 

159C 

5600 

1 



R 



02/Y 05/Y 

8/19/83 

OF 

TIGR 

5194 

15A0 

4 



R 

SP 


04/ Y 

8/19/83 

10 

MRFSRF 

2202 

lAOO 

4 



R 

SP 


02/Y 

8/19/83 

11 

CCAF 

1224 

lAOO 

4 



R 



02/Y 

8/19/83 

12 

LS 

0C42 

lAOO 

4 



R 



02/Y 

8/19/83 

13 

RD 

74E0 

0000 

4 


p 

R 

SP 



8/30/83 

14 

VB 

6DEC 

0000 

4 


p 

R 

SP 



8/30/83 

15 

CP 

4FF0 

lAOO 

4 


p 

R 



02/Y 

8/19/83 

16 

lOBREAK 

023C 

COOO 

0 

S 

p 

R 

RU 


01/Y 

8/19/83 

17 

SVS 

1E28 

0000 

4 


p 

R 




8/19/83 

18 

RVI 

0A48 

lAOO 

4 


p 

R 

SP 


02/Y 

8/19/83 

19 

RESTART 

399A 

COOO 

0 

S 

p 




01/Y 

8/19/83 

lA 

ANALZ 

65B2 

lAOO 

1 


p 

R 



02/Y 

8/19/83 

IB 

IFSVC 

2108 

lAOO 

4 


p 

R 

SP 


02/Y 

8/19/83 

1C 

XBJS 

2454 

lAOO 

4 



R 



02/Y 

8/19/83 

ID 

MPFMKF 

2090 

lAOO 

4 



R 



02/Y 

8/19/83 

IE 

SCS 

24F6 

COOO 

4 

S 

p 

R 



01/Y 

8/19/83 

IF 

PMSBID 

02F4 

COOO 

0 

S 

p 




01/Y 

8/19/83 

20 

lUV 

0D58 

COOO 

0 

S 

p 


SP 


01/Y 

8/19/83 

21 

LG FORM 

3F2A 

COOO 

0 

S 

p 


RU 


01/Y 

8/19/83 

22 

DD 

1B92 

lAOO 

4 



R 



02/Y 

8/19/83 

23 

LD 

22EE 

lAOO 

4 



R 



02/Y 

8/19/83 

24 

LLR 

1D4A 

lAOO 

4 



R 



02/Y 

8/19/83 

25 

PMPINS 

25C0 

COOO 

0 

s 

p 

R 



01/Y 

8/19/83 

26 

MPISPI 

1B70 

lAOO 

4 



R 

SP 


02/Y 

8/19/83 

27 

SMS 

0D98 

COOO 

4 

s 

p 

R 



01/Y 

8/19/83 

28 

PMPDEL 

1CA4 

COOO 

0 

s 

p 

R 



01/Y 

8/19/83 

29 

CKR 

1580 

lAOO 

4 



R 

SP 


02/Y 

8/19/83 

2A 

IDT 

0952 

lAOO 

4 




SP 


02/Y 

8/19/83 

2B 

SIS 

304C 

COOO 

4 

s 

p 

R 



01/Y 

8/19/83 

2C 

MADS AD 

1576 

lAOO 

4 


p 

R 

SP 


02/Y 

8/19/83 

2D 

PMRWTK 

029C 

COOO 

0 

s 

p 


RU 


01/Y 

8/19/83 

2E 

SCU 

3130 

COOO 

4 

s 

p 

R 

SP 

49 

01/Y 

8/19/83 

2F 

SND 

0A74 

lAOO 

4 



R 



02/Y 

8/19/83 
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Table 21- 

2 Ma 

p of 

Utl 

1 1 1 y 

Program 

File 

( Continued ) 


30 

SJSSTS 

2AEE 

COOO 

4 

S 

P 

R 



01/Y 

8/19/83 

31 

PMPMAP 

0D7A 

COOO 

0 

S 

P 

R 

RU 


01/Y 

8/19/83 

32 

MD 

2C12 

lAOO 

4 



R 



02/Y 

8/19/83 

33 

SYSGEN 

6EC2 

0000 

4 



R 



03 

8/19/83 

34 

CD 

67C6 

0000 

4 


P 

R 


SP 


8/30/83 

35 

BD 

6258 

0000 

4 


P 

R 


SP 


8/30/83 

36 

VC 

5C68 

0000 

4 


P 

R 


SP 


8/30/83 

37 

PMPASP 

1978 

COOO 

0 

S 

P 

R 



01/Y 

8/19/83 

38 

INV 

IFFE 

COOO 

0 

S 

P 

R 


SP 

01/Y 

8/19/83 

39 

AUIDUI 

34C0 

lAOO 

4 






02/Y 

8/19/83 

3A 

CRV 

0D5C 

COOO 

4 

S 

P 

R 


SP 

01/N 

8/19/83 

3B 

LTS 

1794 

COOO 

4 

S 


R 



01/Y 

8/19/83 

3C 

BMF 

307E 

lAOO 

4 



R 



02/Y 

8/19/83 

3D 

LGGLOG 

0606 

COOO 

0 

S 

P 




01/Y 

8/19/83 

3E 

MOEMPE 

2D24 

lAOO 

4 


P 

R 



02/Y 

8/19/83 

3F 

CPI 

1CE6 

0000 

4 


P 

R 


SP 


8/19/83 

40 

MKL 

0FE8 

lAOO 

4 


P 

R 



02/Y 

9/13/83 

41 

CVD 

3E08 

0000 

4 


P 



SP 


8/19/83 

42 

MVI 

ICDA 

0000 

4 


P 

R 


SP 


8/19/83 

43 

NAMMGR 

20 DO 

COOO 

0 

S 

P 



SP 

01/Y 

8/19/83 

44 

RAL 

06C8 

COOO 

4 

S 

P 

R 



01/Y 

8/19/83 

45 

CSKCKS 

1B9C 

lAOO 

4 



R 



02/Y 

8/19/83 

46 

RWCRU 

OAIE 

lAOO 

4 


P 

R 



02/Y 

8/19/83 

47 

LGACCT 

301A 

COOO 

0 

S 

P 


RU 


01/Y 

8/19/83 

48 

JOBMGR 

26E4 

COOO 

0 

S 

P 


RU 

SP 

01/Y 

8/19/83 

49 

BEMF 

2D92 

lAOO 

4 



R 



02/Y 

8/19/83 

4A 

PMSBUF 

0562 

COOO 

0 

S 

P 




01/Y 

8/19/83 

4B 

IBMUTL 

1EF2 

0000 

4 


P 

R 




8/19/83 

4C 

RPRCP 

254C 

COOO 

0 

S 

P 

R 

RU 

SP 

01/Y 

8/19/83 

4D 

SP$DST 

4A0A 

IICO 

1 


P 



SP 

06/Y 

8/19/83 

4E 

SPINIT 

1C22 

IICO 

1 





SP 

06/Y 

8/19/83 

4F 

ASP 

0D36 

lAOO 

4 



R 



02/Y 

8/19/83 

55 

SEM 

303E 

lAOO 

4 



R 



02/Y 

8/19/83 

56 

IDS 

4A0E 

0000 

4 


P 

R 


SP 


8/19/83 

57 

PF 

227A 

lAOO 

4 



R 



02/Y 

8/19/83 

58 

MLP 

0C3E 

COOO 

4 

S 


R 



01/Y 

8/19/83 

59 

LPWRITER 

1F54 

4580 

4 



R 

RU 


07/Y 

8/19/83 

5A 

LGACHN 

01B2 

COOO 

0 

S 

P 

R 



01/Y 

8/19/83 

5B 

SPTASK 

0A80 

0000 

4 



R 




8/19/83 

5C 

ALN 

3940 

lAOO 

4 



R 



02/Y 

8/19/83 

5D 

DCOPY 

41CA 

0000 

4 


P 



SP 


8/19/83 

5E 

CSM 

3850 

0000 

4 







8/19/83 

5F 

SCINIT 

0CA4 

lAOO 

1 



R 



02/Y 

8/19/83 

60 

SOS 

3332 

lAOO 

4 



R 



02/Y 

8/19/83 

61 

OPERATOR 

3D92 

COOO 

1 

S 





01/Y 

8/19/83 

62 

XOI 

4A5E 

lAOO 

4 



R 



02/Y 

8/19/83 

63 

LGRCRT 

25B6 

COOO 

4 

S 



RU 


01/Y 

8/19/83 

64 

LSC 

2F24 

lAOO 

4 



R 



02/Y 

8/19/83 

65 

CB 

2436 

lAOO 

4 



R 



02/Y 

8/19/83 

66 

SRFI 

OFEC 

lAOO 

4 


P 

R 


SP 

02/Y 

8/19/83 

67 

DEBUG 

OFFA 

COOO 

4 

S 

P 

R 



01/Y 

8/19/83 
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Table 21-2 Map of Utility Program File (Continued) 


68 SAVRES 

12B2 

COOO 

0 

S 

P 

R 

01/Y 

8/19/83 

6F TPCALANS 

0F72 

0000 

4 



R 


8/19/83 

70 TPDISC 

0CF8 

0000 

4 



R 


8/19/83 

71 TPMHPC 

0F5A 

0000 

4 



R 


8/19/83 

72 TPLHPC 

OEDE 

0000 

4 



R 


8/19/83 

74 XJM 

193E 

COOO 

1 

S 

P 

R 

01/Y 

8/19/83 

75 DIOU 

OFEC 

COOO 

0 

S 

P 

R SP 

01/Y 

8/19/83 

83 MCDT 

1912 

0000 

4 



R 


8/19/83 

85 BDD 

A934 

0000 

4 


P 

SP 


8/19/83 

86 CV 

5EC0 

0000 

4 


P 

SP 


8/19/83 

87 CVINIT 

515E 

0000 

4 


P 

R SP 


8/19/83 

88 SD 

D800 

0000 

4 


P 

R 


8/19/83 

8E RESOLVE 

0C7C 

lAOO 

4 



R 

02/Y 

8/19/83 

8F XBJM 

03A4 

0000 

4 



R SP 


8/19/83 

90 RESTART2 

2C24 

COOO 

0 

S 

P 


01/Y 

8/19/83 

93 TFTPC 

52C4 

0000 

4 



R 


8/19/83 

PROCEDURE/ PROGRAM 

SEGMENTS; 

MA)^ 

: POSSIBLE = 20 



ID NAME 

LENGTH 

LOAD 

S M 

R 

D 

U SH RU CP E W C OVLY 


DATE 

02 S$ SYSTEM 

19F6 

0000 




SH W 


8/19/83 

03 SCI990 

6586 

lAOO 




SH W 


8/19/83 

04 TIGRESS 

159A 

0000 




SH 


8/19/83 

05 EDITOR 

3BEC 

lAOO 




SH 


8/19/83 

06 SPCOMN 

IIBC 

0000 




SH E 


8/19/83 

07 LPWRITER 

4576 

0000 




SH W 


8/19/83 

OVERLAYS: ] 

MAX POSSIBLE = 

96 





ID NAME 

LENGTH 

LOAD 

MAP 

D 

OVLY 


DATE 

01 INIT 

1572 

21E0 






8/19/83 

02 INTERACT 

4CE2 

21E0 




01 


8/19/83 

03 BUILD 

4C2A 

21E0 




02 


8/19/83 

04 VERSION 

0006 

0000 

MAP 





8/19/83 

41 SCUINIT 

0C4C 

E492 






8/19/83 

42 SCUDEV 

0478 

E492 




41 


8/19/83 

43 SCULDC 

05C2 

E90A 




42 


8/19/83 

44 SCUADD 

0434 

E492 




4E 


8/19/83 

45 SCUPDT 

0580 

E8C6 




44 


8/19/83 

46 SCUDSR 

045A 

E8C6 




4B 


8/19/83 

47 SCUDEL 

05B6 

E90A 




4F 


8/19/83 

48 SCUMISC 

0A98 

E492 




53 


8/19/83 

49 SCUMSP 

0B70 

E492 




48 


8/19/83 

4 A SCUAINT 

05C4 

E8C6 




46 


8/19/83 

4B SCUNAME 

0462 

E8C6 




4D 


8/19/83 

4C SCUPDl 

040C 

E8C6 




45 


8/19/83 

4D SCUPD2 

055A 

E8C6 




4C 


8/19/83 

4E SCUMDS 

043C 

E90A 




47 


8/19/83 

4F SCUDATA 

0558 

E90A 




43 


8/19/83 

53 SCUAMUX 

02A6 

EES A 




54 


8/19/83 

54 SCUAEXP 

0248 

EE8A 




4A 


8/19/83 
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Table 21-3 Map of System Program File 
FILE MAP OF .S$SHIP 

TODAY IS 13:35:05 TUESDAY, SEPTEMBER 27, 1983. 

TASK SEGMENTS: MAX POSSIBLE = 8 


ID NAME 

LENGTH 

LOAD 

PRI 

S 

P 

M R D U RU 

CP E 0 C SP B 

OVLY 

Pl/S P2/S 

DATE 

02 PMTBID 

0A12 

COOO 

0 

S 

P 

M 

SP 


01/Y 

8/19/83 

03 lOU 

3 DA A 

COOO 

0 

S 

P 

RU 

SP 

14 

01 /Y 

8/19/83 

04 PMTLDR 

18E0 

COOO 

0 

S 

P 

M 

SP 

15 

01/Y 

8/19/83 

05 FILEMGR 

380A 

COOO 

0 

S 

P 

M 

SP 

05 

01/Y 

8/19/83 

06 DISKMGR 

0730 

COOO 

0 

S 

P 

M 


11 

01/Y 

8/19/83 

07 PMOVYL 

047 C 

COOO 

0 

S 

P 


SP 


01/Y 

8/19/83 

08 PMWRIT 

02C6 

COOO 

0 

S 

P 

M 

SP 


01/Y 

8/19/83 

PROCEDURE/PROGRAM 

SEGMENTS: 

; MAX POSSIBLE = 

2 




ID NAME 

LENGTH 

LOAD 

S M 

R 

D 

U SH RU CP 

E W C OVLY 



DATE 

01 ROOT 

3464 

0000 




U 




8/19/83 

02 S$SHIP 

39AA 

3480 




u 




8/19/83 


OVERLAYS: MAX POSSIBLE = 69 


ID 

NAME 

LENGTH 

LOAD MAP 

D OVLY 

DATE 

01 

SMTAOl 

008A 

9000 


8/19/83 

03 

SVCSHD 

3800 

COOO 


8/19/83 

04 

SVCTWO 

3800 

COOO 


8/19/83 

05 

KORW 

0392 

F80A 

16 

8/19/83 

06 

FORWFB 

03F0 

F80A 


8/19/83 

07 

FOMISC 

0158 

F80A 

06 

8/19/83 

08 

FOXFIL 

024C 

F80A 

07 

8/19/83 

09 

FOOPEX 

0366 

F80A 

08 

8/19/83 

OA 

KOINSR 

03E8 

F80A 

09 

8/19/83 

OB 

KODLSR 

02E2 

F80A 

OA 

8/19/83 

OC 

KOOPCL 

03 D2 

F80A 

OB 

8/19/83 

OD 

KOBDEL 

025C 

F80A 

OC 

8/19/83 

OE 

KOBTIS 

03A8 

F80A 

OD 

8/19/83 

OF 

KORWS 

038 E 

F80A 

OE 

8/19/83 

10 

DMOV37 

02A6 

C48A 


8/19/83 

11 

DMOV38 

0280 

C48A 

10 

8/19/83 

12 

CFOVLY 

0F44 

EE66 


8/19/83 

13 

lUMISCOV 

0C18 

EE66 

12 

8/19/83 

14 

lURFAADA 

0C74 

EE66 

13 

8/19/83 

15 

PMERRS 

0212 

D8E0 


8/19/83 

16 

KOPLG 

01A6 

F80A 

OF 

8/19/83 

IB 

DSRDSK 

ODOC 

COOO 


8/19/83 

20 

DSR911 

1226 

COOO 


8/19/83 

3C 

JCAOOO 

3000 

9000 


8/19/83 

43 

DSR93B 

35C6 

COOO 


8/19/83 

44 

DSR93C 

379A 

COOO 


8/19/83 
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SECTION 22 

DATA STRUCTURE PICTURES 


22.1 OVERVIEW 

This section Includes details of the templates found in the 
DSC. TEMPLATE. COMMON directory and In the DSC . TEMPLATE . ATABLE 
directory. The D SC . TEMPLATE . COMMON directory Includes templates 
for the tables used as assembly language CSEC modules throughout 
DNOS. It also includes special-purpose templates used only by a 
single subsystem. The special-purpose templates are not shown In 
detail here; consult the appropriate TEMPLATE directory for 
de tai Is . 

The DSC . TEMPLATE . ATABLE directory contains all of the assembly 
language versions of the DNOS data structure templates. It 
includes templates for structures used throughout the operating 
system as well as templates for special purposes In a single 
subsystem. This section Includes detailed pictures of the 
general-purpose structures; consult the source directory for 
details on special-purpose structures. 

The template pictures Include descriptions of various fields of 
data structures used by DNOS, their locations, meanings of flags, 
and special comments. The following features are found In one or 
more of the structure pictures: 

* Header showing the structure name, location In the 
system, and abbreviation for the name 

* Comments describing the use of the structure 

* Hexadecimal starting location (or offset relative to the 
beginning of the structure) for each word of the 
structure 

* Label for each field, chosen from three types: 

- Blank if no label 

- Label of the form FILLxy, if the label Is 
generated by software 

- Label of 6 or fewer characters 
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* Size of field Indicated by space allocated In structure 
picture 

* Comment to right of field, describing that field 

* List of flag definitions for each flag field In the 
s t rue t ure 

- Flag name 

- Diagram showing position of flag. Initial position 
being 0. The flag Is always defined as an 
assembly language equate for the first bit 
position shown with an X In the diagram. 

Description of flag 

- Optional lines of extended explanations of flag 
settings 

* List of equated labels for fields In the structure 

- Label being equated 

- Argument of the equate 

- Value of the equate (or location of the argument) 

- Description of the label being equated 

Table 22-1 lists the templates detailed In this section. 
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Table 22-1 Template Acronyms 
Acronym Meaning 


From DSC. TEMPLATE . COMMON 


JMDATA 

LGACOM 

LGLCOM 

NFCLKD 

NFDATA 

NFJOBC 

NFPTR 

PMDATA 


Job Management Common Area In JCA 

Accounting Log Common Data 

System Log Common Data 

Clock Data Area 

Global Data Values 

Job Manager Common Area 

System Pointers 

Global Data Areas for Program Management 


From DSC. TEMPLATE .ATABLE 


ACC 

ADR 

AGR 

BAP 

BRO 

BTB 

CCB 

CDE 

CDR 

CLR 

DDB 

DIA 

DIT 

DOR 

DPD 

DPR 

DUS 

FCB 

FDB 

FDP 

FDR 

FID 

FIR 

FSC 

FWA 

IRB 

JIT 

JMR 

JSB 

KCB 

KDB 

KDR 

KIB 

KIT 


Accounting Record Contents 
Allas Descriptor Record 
Access Group Record 
Buffer Address Packet 
Buffered Request Overhead 
B-Tree Block 
Channel Control Block 
Command Definition Entry 
Channel Descriptor Record 
Capabilities List File Record 
DIOU Data Base Definition 
Diagnostic Status 
Disk Information Table 
Directory Overhead Record 
Disk PDT Extension 
Device Utility Parameters 
Device Utility Session Table 
File Control Block - See FSC 
File Directory Block - See FSC 
File Descriptor Packet 
File Descriptor Record 
File Identification 
File Information Record 
File Structure Common 
File Manager Work Area 
I/O Request Block 
Job Information Table 
Job Management Request 
Job Status Block 
KIF Currency Block 

Key Descriptor Block (Memory Structure) 
Key Descriptor Block (Disk Structure) 
KIF Information Block 
KIF Task Area 
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Table 22-1 Template Acronyms (Continued) 


Acronym 

Meanl ng 

KSB 

Keyboard Status Block 

LDT 

Logical Device Table 

LFD 

Log File Definition 

LPD 

Line Printer PDT Extension 

LSE 

Load Segment Entry 

MRB 

Master Read/Master Write Buffer 

MTX 

Extension for a Magnetic Tape 

NDB 

Name Definition Block 

NDS 

Name Definition Segment Overhead 

NFCRSH 

System Crash Code Equates 

NFSTAT 

Task State Definitions 

NRB 

Name Manager Request Block 

OAD 

Overlay Area Description 

OAW 

Overlay Area Walt Block 

OSE 

Owned Segment Entry 

OTI 

Opening Task Identifier 

OVB 

Overhead Beet 

OVT 

Overlay Table Entry 

PBM 

Partial Bit Map Table/Buffer 

PDT 

Physical Device Table 

PFI 

Program File Directory Index Entry 

PFZ 

Program File Record Zero 

QHR 

Queue Header 

QIR 

Queued IPC Request 

RDB 

Request Definition Block 

RIB 

Return Information Block 

RLT 

Record Lock Table 

ROB 

Resource Ownership Block 

RPB 

Resource Privilege Block 

RST 

Reserve Segment Table 

SAT 

Secondary Allocation Table 

SCO 

Track 0, Sector 0 

SDB 

Stage Descriptor Block 

SGB 

Segment Group Block 

SLB 

System Log Block Formats 

SLH 

Semaphore List Header 

SMR 

Segment Manager Request Block 

SMT 

Segment Manager Table 

SOB 

Segment Owner Block 

SOV 

System Overlay Load Table 

SSB 

Segment Status Block 

STA 

System Table Area Overhead 

STE 

Swap Table Entry 

SVB 

Stage Value Block 

TDL 

Time Delay List Entry 

TSB 

Task Status Block 
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Table 22-1 Template Acronyms (Continued) 


Acronym 


Meaning 


UDO 

UDR 

UIP 

VCB 

VDB 

VRB 

XTK 


User Descriptor Overflow Record 
User Descriptor Record 
User ID Parameter 
Value Continuation Block 
Value Definition Block 
Virtual Request Block 

Extension for a Terminal with a Keyboard 


Several templates are described In the DNOS SCI and Utilities 
Design Document , along with detailed descriptions of the 
utilities that use them. Table 22-2 lists the templates 
described In that manual. 


Table 22-2 Templates Described In SCI and Utilities Document 
Acronym Meaning 


ACC 

CNT 

FIR 

SCA 

SDEDOR 

SDEMD 

SDQ 

SDT 

SPM 

UDR 


Accounting Record Contents 

Class Name Table 

File Information Record 

System Communications Area 

Memory Resident DOR (UTSORT Structure) 

Sorted Directory File Entries Table 

Spooler Device Queue Entry 

Spooler Device Table Entry 

Spooler Message Format 

User Descriptor Record 
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22.2 STRUCTURES FROM THE COMMON DIRECTORY 


**************************************************** 

* 

* JMDATA - JOB MANAGER COMMON AREA 06/08 

* LOCATED IN JOB MANAGER TASK AREA 

* 

**************************************************** 

* 


******** 

* 

/82 * 
* 
* 

******** 


* 1 * 

>00 ! CURJSB ! CURRENT JSB POINTER 

+ + + 

>02 ! JMRPTR ! CURRENT JOB REQUEST 

+ + + 

>04 ! BROPTR ! CURRENT BRO REQUEST 

>06 ! PARFMT ! PARENTS FMT POINTER 

+ + + 

>08 ! PARFCB ! PARENTS FCB POINTER 

+ + + ==== = = = = = = » = = = = JOB & TASK STATES 

>0A ! JSTCRE ! JSTEXC ! CREATING 

+ + + EXECUTABLE 

>0C ! JSTHLT ! JSTTRM ! HALTED 

+ + + TERMINATING 

>0E ! TSTJHT ! TSTJMR ! TASK SUSPENDED BY JOBMGR 

+ + + task waiting on JMR SVC 
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LGACOM 




* * 

* LGACOM - ACCOUNTING LOG COMMON 04/26/82 * 

* TEMPLATE : LED * 

* (40 MAX = 2 KB OF MESSAGES) * 


************************************************************ 


— — ._.* 


>00 

I 

FILLOO 

! 

>02 

“T — 

I 

FILLOl 

1 

m-L. 

>04 

I 

FILL02 ! FILLOS 

j 

>06 

“r“ 

FILL04 

} 

— 1- 

>08 

1 

+- 

FILL05 ! 

+ 

j 

-+ 


FLAGS AND ERROR BYTE 

MAX MESSAGE COUNT (0 = NONE) 

ID OF TASK TO BID ON FULL 

ID OF USER TASK TO BID ON FULL 
ACCOUNTING FILE ALLOCATION 

LUNOS 


EQUATES : 


LABEL EQUATE TO VALUE DESCRIPTION 


LGACOM $ >00 


+ 
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* * 


* LGLCOM - SYSTEM LOG COMMON 09/09/83 * 

* TEMPLATE : LED * 

* * 
*:*:********************************************************** 


•k-^ -->H •“* 


>00 

f 

FILLOO 

f 

FLAGS (SEE LFD TEMPLATE) 

>02 

“r — 

f 

FILLOl 

“•"r 

J 

MAX MESSAGE COUNT (0=>NO MAX) 

>04 

“T" 

I 

FILL02 

! FILL03 

j 

ID OF TASK TO BID ON FULL 

ID OF USER TASK TO BID ON FULL 
LOG DEVICE NAME ( BLANKS=> NONE ) 

>06 

"r“" 

f 

_L 

FILL04 

f 

-J_ 

I 

-4- 

>08 

I 


1 

_l- 

f 

— 4- 


>0A 

J 

FILL05 

I 

J 

1^4. 

FILENAME 1 


"r“" 

/ 

/ 


/ 

/ 

/ 

/ 


>12 

”r"“ 

1 

FILL06 

f 

j 

-4- 

FILENAME 2 


/ 

/ 


/ 

/ 

/ 

/ 

— 4- 


>1A 

I 

FILL07 

j 

»4. 

LOG FILE ALLOCATION 

>1C 

I 

+- 

FILL08 

j 

-+ 

j 

-+ 

LUNOS 


EQUATES : 



LABEL 

EQUATE TO 

VALUE DESCRIPTION 

LGLCOM 

$ 

>00 
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NFCLKD 


•k’k-kick’ifk-kickifkickifk’kic-kifkicifk'k'k'kic-k-kiticicieic-k-kjfk'kifkickieidc^t’kick-kick-k'kickick 
* * 

* NFCLKD - CLOCK DATA AREA 01/31/82 * 

* * 

* THIS COMMON SEGMENT INCLUDES FLAGS AND COUNTERS USED FOR 

* PERFORMANCE DATA GATHERING AND SYSTEM CLOCK WORKSPACES. 

* THE WORKSPACE STARTING AT CLKWP2 IS USED FOR UPDATING THE 

* CLOCK; THAT AT CLKWP IS THE NORMAL CLOCK WORKSPACE. IN 

* THE LATTER, THE ESTIMATED UTILIZATION VARIABLES (R4,R5) 

* CONTAIN VALUES IN THE RANGE 0 THROUGH >8000 WHERE 0 

* REPRESENTS 0% UTILIZATION AND >8000 REPRESENTS 100% 

* UTILIZATION. 

* 


* 1 * 

>00 ! NBFLGS ! 


>02 

f 

+ 

NBSAMl 

1 

>04 

f 

NBSAM2 

J 

>06 

— •• *■ 

I 

STFLGO 

! 

>08 

1 

FLGOHl 

1 

>0A 

1 

FLG0H2 

-U 

1 

>0C 

1 

STFLGl 

1 

>0E 

t 

FLGIHI 

f 

>10 

i 

FLG1H2 

J- 

1 

>12 

I 

STFLG2 

1 

>14 

I 

FLG2H1 

f 

>16 

j 

FLG2H2 

{ 

>18 

"T— • 

1 

STFLG3 

j 

>1A 

1 

FLG3H1 

1 

>1C 

T"— — — - 

f 

FLG3H2 

f 

>1E 

"T — 

I 

STFLG4 

j 

>20 

T" — — - 

J 

FLG4H1 

! 

>22 

“T — • 

I 

FLG4H2 

t 
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NUMBER OF STATISTIC FLAGS 


NUMBER SAMPLES ON FLAGS (WD 1) 
NUMBER SAMPLES ON FLAGS (WD 2) 


FLAG 

0 - 

FOR ] 

DISK 

utility 


HIT 

COUNT 

FOR 

FLAG 

0 

( WD 

1) 

HIT 

COUNT 

FOR 

FLAG 

0 

( WD 

2) 

FLAG 

1 - 

CPU 1 

UTILIZATION 


HIT 

COUNT 

FOR 

FLAG 

1 

( WD 

1) 

HIT 

COUNT 

FOR 

FLAG 

1 

( WD 

2) 

FLAG 

2 - 

SCHEDULER 




HIT 

COUNT 

FOR 

FLAG 

2 

( WD 

1) 

HIT 

COUNT 

FOR 

FLAG 

2 

( WD 

2) 

FLAG 

3 - 

FILE 

MANAGER 


HIT 

COUNT 

FOR 

FLAG 

3 

( WD 

1) 

HIT 

COUNT 

FOR 

FLAG 

3 

( WD 

2) 

FLAG 

4 - 

TASK 

LOADER 



HIT 

COUNT 

FOR 

FLAG 

4 

( WD 

1) 

HIT 

COUNT 

FOR 

FLAG 

4 

( WD 

2) 

9 
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>24 

f 

+ 

STFLG5 

i 

>26 

J 

FLG5H1 

1 

>28 

I 

FLG5H2 

1 

>2A 

j 

STFLG6 

f 

>2C 

i 

FLG6H1 

J 

>2E 

j 

FLG6H2 

1 

>30 

1 

STFLG7 

j 

>32 

1 

FLG7H1 

I 

>34 

! 

FLG7H2 

j 

>36 

I 

STFLG8 

! 

>38 

1 

FLG8H1 

I 

>3A 

1 

FLG8H2 

1 

>3C 

I 

STFLG9 

j 

>3E 

1 

FLG9H1 

I 

>40 

f 

FLG9H2 

I 

>42 

1 

STFLGA 

1 

>44 

f 

FLGAHl 

1 

>46 

f 

FLGAH2 

! 

>48 

I 

STFLGB 

f 

>4A 

1 

FLGBHl 

J 

>4C 

j 

+ 

FLGBH2 

! 

>4E 

1 

STCNTO 

f 

>50 

"T — — — ■ 

I 

STCNTl 

1 

>52 

1 

STCNT2 

-L 

j 

>54 

“f — * • 

! 

STCNT3 

J 

>56 

I 

STCNT4 

t 


FLAG 5 - MAP ONE ACTIVITY 


HIT COUNT 

FOR 

FLAG 

5 

( WD 

1) 

HIT COUNT 

FOR 

FLAG 

5 

(WD 

2) 

FLAG 6 - 1 

SVC CODE 

FILE MGR 

HIT COUNT 

FOR 

FLAG 

6 

(WD 

1) 

HIT COUNT 

FOR 

FLAG 

6 

(WD 

2) 

FLAG 7 






HIT COUNT 

FOR 

FLAG 

7 

(WD 

1) 

HIT COUNT 

FOR 

FLAG 

7 

( WD 

2) 

FLAG 8 






HIT COUNT 

FOR 

FLAG 

8 

(WD 

1) 

HIT COUNT 

FOR 

FLAG 

8 

(WD 

2) 

FLAG 9 






HIT COUNT 

FOR 

FLAG 

9 

(WD 

1) 

HIT COUNT 

FOR 

FLAG 

9 

(WD 

2) 

FLAG 10 






HIT COUNT 

FOR 

FLAG 

10 

(WD 

1) 

HIT COUNT 

FOR 

FLAG 

10 

(WD 

2) 

FLAG 11 






HIT COUNT 

FOR 

FLAG 

11 

( WD 

1) 

HIT COUNT 

FOR 

FLAG 

11 

(WD 

2) 

COUNTER 0 

- # 

JOBS 

COMPLETED 

COUNTER 1 

- # 

TASKS COMPLETED 

COUNTER 2 

- # 

SEG 

MGR 

CALLS 

COUNTER 3 

- # 

FILE 

MGR CALLS 

COUNTER 4 

- # 

IPC 

CALLS 
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NFCLKD 

>58 

I 

STCNT5 

I 

— 4- 

COUNTER 5 - # ROLL OUTS 

>5A 

t 

STCNT6 

t 

-•4. 

COUNTER 6 - # FILE MGR Q REQ 

>5C 

1 

STCNT7 

I 

..4- 

COUNTER 7 - # SYSTEM OVLY LDS 

>5E 

r-^ -uj -L 

I 

STCNT8 

1 

.4. 

COUNTER 8 - # NAME MANAGER CALLS 

>60 

J 

STCNT9 

1 

COUNTER 9 - # lOU CALLS 

>62 

I 

STCNTA 

““T 

I 

m.4. 

COUNTER 10- # SYSTAB SCHED CALLS 

>64 

_i_ 

STCNTB 

t 

»4. 

COUNTER 11 

>66 

1 

CLKWP2 

! 

■»4. 

RO 


>68 

r** -La 

! 

CKTICl 

f 

.4- 

R1 

- 32 BIT CLOCK TIC COUNTER 

>6A 

i 

CKTIC2 

I 

R2 

WORDS 1 AND 2 

>6C 

! 

YEAR 

— X 

1 

R3 

- CLOCK YEAR COUNTER 

>6E 

! 

a. 

DAY 

“X 

f 

_4. 

R4 

- CLOCK DAY COUNTER 

>70 

! 

HOUR 

! 

R5 

- CLOCK HOUR COUNTER 

>72 

r " 

I 

MIN 

■•X 

! 

R6 

- CLOCK MINUTE COUNTER 

>74 

•r " 

1 

SEC 

"X 

! 

R7 

- CLOCK SECOND COUNTER 

>76 

! 

J. 

TIC 

1 

.•4. 

R8 

- CLOCK TIC COUNTER 

>78 

1 

FILLOO 

j 

mmM 

R9 

- SECONDS PER MINUTE 

>7A 

“T 

I 

FILLOl 

“*X 

f 

RIO 

- HOURS PER DAY 

>7C 

“T" " 

f 

a. 

FILL02 

"X 

f 

.4. 

R1 1 

- DAYS PER YEAR 

>7E 

j 

FILL03 

1 

.4- 

R12 

- SCRATCH 

>80 

I 

-j_ 

FILL04 


R13 

- SCRATCH 

>82 

j 

FILL05 

_ I 

R14 


>84 

1 

FILL06 

f 

^4- 

R15 

- TIC COUNT FOR TIME UNITS 

>86 


CLKWP 

f 

i.4. 

RO 

- SCRATCH 

>88 

J 

FILL07 

f 

.4. 

R1 

- SCRATCH 

>8A 

I 

FILL08 

! 

R2 

- SCRATCH 

>8C 

I 

FILL09 

■“X 

J 

R3 

- FOR BAR GRAPH 
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+ 

4- 

1- 



>8E 

i 

DSUTIL 

f 

R4 - 

ESTIMATED DISK UTILIZ 


+ 


4- 



>90 

f 

CPUTIL 

! 

R5 - 

ESTIMATED CPU UTILIZ 


+ 

4- 




>92 

j 

TSTIC 

t 

R6 - 

TIME SLICE TIC COUNT 


4- 

4- 

4- 



>94 

I 

DSPFGl 

1 

R7 - 

INDEX TO FLAGS TO DISPLAY 


4- 


— — — — + 



>96 

i 

DSPFG2 

i 

R8 - 

ON FRONT PANEL 


4- 


— - — h 



>98 

f 

FILLOA 

j 

R9 - 

FOR FRONT PANEL DISPLAY 


4- 


4- 



>9A 

I 

FILLOB 

1 

RIO - 

FOR FRONT PANEL DISPLAY 


4- 

-4- 

— — + 



>9C 

1 

FILLOC 

1 

Rll - 

SCRATCH 


4 

4- 

4- 



>9E 

j 

FILLOD 

1 

R12 - 

FRONT PANAL ADDRESS 


4- 

4- 

4- 



>A0 

j 

FILLOE 

f 

R13 - 

WORKSPACE POINTER 


4- 

4- 

4- 



>A2 

1 

FILLOF 

! 

R14 - 

PROGRAM COUNTER 


4- 

4- 




>A4 

f 

FILLIO 

f 

R15 - 

STATUS 


4- 

4- 

4- 



>A6 

J 

PFG0H2 

! 

PREV 

NUMBER HITS FLAG 0 (WD 2) 


4- 

4- 

— — — — -j- 



>A8 

f 

PFG1H2 

1 

PREV 

NUMBER HITS FLAG 1 ( WD 2) 


4 

4- 

1- 




EQUATES : 




LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 

SFESIZ 

6 

>06 

STATISTICS FLAGS ENTRY SIZE 

NFCSIZ 

$-NBFLGS 

>AA 
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NFDATA 


ick:k^ieifkic-ki:‘k4ckicicki('k-kick:kic:k‘k’k-ki<it:k‘kick4fk‘kitick:kifk"kickifk‘kick‘kifit4ck'it:>fk‘kit 
* * 

* NFDATA - GLOBAL DATA VALUES 03/08/83 * 

* * 
***:*?********************* ****:fe***;)lf******Vlt?lt********5fc********* 

* THIS COMMON SEGMENT CONTAINS GLOBAL DATA VALUES INCLUDING 

* THE FOLLOWING: BEET ANCHORS FOR THE TIME ORDERED LIST 

* (TOL), CACHE LIST, FREE MEMORY LIST, STATIC BUFFER AREA, 

* AND THE TEMPORARY MEMORY BUFFER; PARAMETERS FOR PRIORITY 

* COMPUTATION AND SCHEDULING; ROLL OUT AND LOAD PARAMETERS, 

* A NUMBER OF MISCELLANEOUS DATA VALUES ARE ALSO FOUND IN 

* THIS CSEG. COMMENTS IN THIS TEMPLATE'S SOURCE FILE SHOW 

* PRIORITY, AGING, AND ROLLOUT PARAMETERS. 

* 

* NOTE: CHANGES TO THIS TEMPLATE REQUIRE CORRESPONDING 

* CHANGES TO SYSGEN. 

* 





-* 

>00 

1 

TMTOL 

I 


+- 


-+ 

>02 

I 

TOLBET 

j 


+- 


-+ 

>04 

1 

TMTOLN 

; 


+- 

+ 

-+ 

>06 

t 

TMTOLO 

1 


+- 


-+ 

>08 

! 

TMTTYP 

f 


+ - 


— + 

>0A 

I 

FILLOO 

I 


+ “ 


-+ 

>0C 

1 

FILLO 1 

1 


+ - 


-+ 

>0E 

J 

FILL02 

I 


+- 


-+ 

>10 

f 

FILL03 

j 


+ - 

+ 

-+ 

>12 

t 

FILL04 ! 

I 


+ - 


-+ 

>14 

j 

f 

! 


+- 


— + 

>16 

j 

INTCDT 

1 


+ - 


— + 

>18 

1 

RESPFL ! RESTSK 

! 


+ - 

+ 

— + 

>1A 

f 

RESTRT 

I 


+ - 


- + 

>1C 

j 

FILL05 

j 


+ - 


-+ 

>1E 

1 

RELOCA 

j 


+ - 

+ 

-+ 


START OF TIME ORDERED LIST 
BEET ADDRESS OF TOL HEADER 
FORWARD POINTER 
BACKWARD POINTER 
TYPE OF BLOCK 

SCHEDULER ENTRY VECTOR (WP) 
(PC) 

(ST) 

RESERVED 

FAKE CDT FOR SYSTEM INIT. TASK 

PROGRAM FILE LUNO 

ID OF SYSTEM RESTART TASK 
ID OF USER RESTART TASK 

RELOCATION VALUE FOR LOADER 
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>20 

f 

CHELST 

1 

>22 

I 

CHEBET 

1 

>24 

I 

CHEFWD 

1 

>26 

! 

CHEBKW 

1 

>28 

! 

CHETYP 

1 

>2A 

? 

SMTBMP 

f 

>2C 

I 

4... 

USERPF ! 

! 


/ 

/ 

/ 

/ 

/ 

/ 

>34 

I 

TSKDOA 

1 

>36 

"r*" 

1 

FILL06 

I 

>38 

“r“ 

j 

4.^ 

CPU12 

1 

>3A 

I 

4.. 

AJSBCT 

I 

>3C 

! 

ATSBCT 

1 

>3E 

j 

WTSBCT 

j 

>40 

j 

4.. 

UAHEAD 

1 

>42 

1 

UAPTR 

? 

>44 

"T"" 

1 

4.I. 

UAFWD 

1 

>46 

I 

UABKW 

1 

>48 

f 

4-* 

UABADD 

1 

>4A 

I 

UATLEN 

! 

>4C 

I 

UADSTR 

1 

>4E 

f 

4.. 

UADLEN 

f 

>50 

f 

4... 

UADMIN 

1 

>52 

f 

USEMEM 

f 

>54 

i 

USEFRG 

j 

>56 

( 

+- 

TICFRQ 

+ 

I 


START OF CACHE LIST 

BEET ADDRESS OF LIST HEADER 

FORWARD POINTER 

BACKWARD POINTER 

TYPE OF BLOCK 

SEG MANAGER SCRATCH WORD 

NAME OF PF CONTAINING USER- 

FOR INTERRUPT 2 PROCESSOR TO 

RETURN TASK ERR CODE TO SCHD 
* RESERVED * (SMRID) 

SET IF 990/12 CPU 

ACTIVE JSB COUNT 

ACTIVE TSB COUNT 

COUNT OF TSB'S ON WOM 

START OF FREE USER AREA 

BEET ADDRESS OF BLOCK 

FOWARD LINK POINTER 

BACKWARD LINK POINTER 

START ADDRESS OF USER MEMORY 

TOTAL LENGTH OF USER MEMORY 

START OF DYNAMIC USER MEMORY 

LENGTH OF DYNAMIC USER MEMORY 

MIN AMOUNT OF DYNAMIC MEMORY 

SUM OF ALL CURRENT FREE MEMORY 

NUMBER OF FREE MEMORY FRAGMENT 

CLOCK FREQUENCY (TICS/SEC) 
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NFDATA 


>58 

f 

UNTSLC 

I 


+- 

+ 

-+ 

>5A 

j 

TPU 



+- 

+ 

— + 

>5C 

i 

TSENAB 

f 


+- 

+ 


>5E 

1 

TICLMT 

i 


+- 

+ 

-4- 

>60 

1 

BTAHED 

j 


+- 


-+ 

>62 

! 

BTAPTR 

f 


+- 


-+ 

>64 

I 

BTAFWD 

! 


+ - 

+ 

-+ 

>66 

I 

BTAREV 

j 


+ - 

+ 

-+ 

>68 

1 

BTAADD 

j 


+- 


-+ 

>6A 

1 

BTALEN 

I 


+ - 

+ 

-+ 

>6C 

I 

BTAMAX 

1 


+- 

+ 

-+ 

>6E 

1 

BTAALL 

1 


+- 

+ 

-+ 

>70 

1 

BTAHDN 

! 


+- 


-+ 

>72 

! 

FILL07 ! 

1 


+- 

+ 

-+ 

>74 

I 

MEMSIZ 

f 


+- 

+ 

-+ 

>76 

j 

CMEMSZ 

j 


+- 

+ 

-+ 

>78 

! 

CRSHTL 

I 


+- 



-+ 

>7A 

J 

CRSHHD ! CRSHSC 

1 


+- 

+ 

-+ 

>7C 

1 

CRSHCL 

1 


H — 

+ 

-+ 

>7E 

j 

CRSHSL 

f 


+- 

+ 

-+ 

>80 

J 

TMBHED 

1 


+- 


- + 

>82 

j 

TMBPTR 

1 


+- 

+ 


>84 

I 

TMBFWD 

I 


+- 

+ 

-+ 

>86 

! 

TMBBWD 

1 


+- 

+ 

-+ 

>88 

! 

TMBADD 

1 


+ - 

+ 

-+ 

>8A 

1 

TMBLEN 

1 


+ - 

+ 

- + 

>8C 

I 

FILL08 

1 


CLOCK TICS PER TIME SLICE 

TICS PER TIME UNIT 

TIME SLICE ENABLE FLAG 

LIMIT FOR CURRENT TIME SLICE 

SIZE OF ANCHOR BLOCK 

BEET ADDRESS OF THIS BLOCK 

FORWARD POINTER 

REVERSE POINTER 

BEET ADDRESS OF TABLE AREA 

LENGTH OF TABLE AREA IN BEETS 

MAXIMUM AREA FOR BUFFERS 

ALLOCATED TABLE AREA 

HIDDEN TABLE AREA 

RESERVED 

SIZE OF SYSTEM IN BEETS 

SIZE OF CRASH FILE IN BEETS 

CRASH FILE TILINE ADDRESS 

CRASH FILE HEAD ADDRESS 

CRASH FILE SECTOR ADDRESS 
CRASH FILE CYLINDER ADDRESS 

CRASH FILE TILINE SELECT 

SIZE OF ANCHOR BLOCK 

BEET ADDRESS OF THIS BLOCK 

FORWARD POINTER 

BACK POINTER 

TEMP ADDRESS BOUNDARY 

TEMP BUFFER LENGTH 

RESERVED 
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+- 

+ 

+ 

>8E 

j 

FILL09 

1 


+- 

+ 

-f. 

>90 

1 

EXTIME 

1 


+- 

+ 

+ 

>92 

f 

FUTPDT 

j 


+- 

+ 

+ 

>94 

1 

UNLPDT 

1 


+- 


— — — — + 

>96 

I 

SYSUNT 

1 


+- 

+ 

+ 

>98 

j 

JCABT 

1 


+- 

+ 

+ 

>9A 

f 

TDLEXP 

j 


+- 

+ 

+ 

>9C 

1 

WJSBCT 

! 


+- 

+ 


>9E 

i 

LDTDSC ! 

! 


+- 


+ 


/ 

/ 

/ 


/ 

/ 

/ 


+- 

+ 

— — — — + 

>AC 

I 

lOINDX 

! 


+- 

+ 

+ 

>AE 

1 

INTPRI ! 

j 


+- 

+ 

— + 

>B0 

f 

I 

j 


+- 


+ 

>B2 

1 

JPRMOD ! 

I 


+- 

+ 

+ 

>B4 

1 

1 

f 


+- 


+ 

>B6 

J 

DYNMOD ! 

I 


+- 

+ 

+ 

>B8 

I 

! 

! 


+- 


+ 

>BA 

I 

AGEIND ! 

1 


+- 

+ 

+ 

>BC 

J 

1 

1 


+- 

+ 

+ 

>BE 

! 

ENDLMT 

f 


+- 

+ 


>C0 

f 

CLMXBF 

j 


+- 

+ 

+ 

>C2 

f 

CLMXPS 

f 


+- 

+ 

+ 

>C4 

f 

CLMNBF 

1 


+- 

+ 

+ 

>C6 

I 

CLNBUF 

1 


+- 

+ 

+ 

>C8 

I 

CLNPRG 

I 


+- 

+ 

+ 

> CA 

1 

TLSPND 

I 


RESERVED 

EXTEND TIME SLICE FLAG 
lOU PDT CURRENTLY IN USE 
UNLOAD VOLUME PDT IN USE 
ELASPED SYSTEM TIME UNITS 
BEET ADDRESS OF JCA 
TIME DELAY EXPIRED FLAG 
WOM LIST JSB COUNT 


VALUE OF X IN I/O INDICATOR 
FORMULA. 

INSTALLED PRI 1 -> 188 


VALUE FOR INSTALLED PRI OF 1 


VALUE FOR installed PRI OF 1 


VALUE FOR installed PRI OF 1 


END ACTION EXECUTION TIME LIMIT 
IN SYSTEM TIME UNITS 
MAX # BUFFERS ON CACHE LIST 

MAX # PROGRAM SEGS ON CACHE LIST 

RESERVED 

WAS MIN # BUFFERS ON CACHE LIST 

# BUFFERS CURRENTLY ON CACHE LIST 

# PROG SEGS CURRENTLY ON CACHE LIST 


MIN # SYS TIME UNITS TASK MUST 
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+ + + BE SUSPENDED BEFORE ELIGIBLE FOR 

>CC ! TLEXEC ! MIN # SYS TIME UNITS OF EXECUTION 

+ + + TASK MUST RECEIVE BEFORE 

>CE ! TOLCNT ! # TASKS ON TOL ELIGIBLE FOR ROLL 

+ + + OUT (NOT MEMORY RESIDENT) 

>D0 ! TOLS24 ! IF NOT 0 STATE 24 TASKS ARE 

+ + + IMMEDIATELY ELIGIBLE FOR 

>D2 ! LDRTDY ! TASK LOADER TIME DELAY VALUE 

+ + + IN SYSTEM TIME UNITS 

>D4 ! NUMROL I NUMBER OF SEGMENTS ROLLED OUT 

+ + + 

>D6 ! ROLSPA ! AMOUNT OF ROLL SPACE USED 

H — + — — — — -4- 

>D8 ! LDREXC ! TASK LOADER IS EXECUTING FLAG 

+ 4- 4- 

>DA ! TSKCNT ! COUNT OF TASKS IN SYSTEM 

+ + + 

>DC ! FRCROL ! FORCED ROLL-OUT COUNT 

+ + + 

>DE ! PMSTSB ! ADDRESS OF TSB TO ROLL 

4- + + 

>E0 ! SITENM ! ! SITE NAME 

+ + 4- 

/ / / 

/ / / 

4- + + 

>E8 ! MGRCG ! ! SYSTEM MANAGER CONTROL GROUP 

4 — _ — _ — — 4._. ____~4. 

/ / / 

/ / / 

4- + 4- 

>F0 ! PUBLIC ! ! PUBLIC ACCESS GROUP 

4- — — — 1 — — — — — 1- 

/ / / 

/ / / 

H 1 H 

>F8 ! SYSOPT ! SYSGEN OPTIONS WORD(FLAGS BELOW) 

-I — — -.—4- 

>FA ! JCARES ! RESERVED TABLE AREA AMOUNT 

H — 1 — — 

>FC ! EXPLEN ! LENGTH TO EXPAND TABLE AREA 

-I — — — _ — _-_-._4. 

>FE ! CONTRY ! COUNTRY CODE FOR THIS SYSTEM 

H — — — — — — — — — — — 4- 

>0100 ! ITSKMX ! MAX ALLOC FOR GET AND PUT DATA 

H 1 H 

>0102 ! ITSKCR ! CURR ALLOC FOR GET & PUT DATA 

_l 1 

>0104 ! DCPYAC ! DCOPY ACTIVE INDICATOR 

4- 4- 4- 0=DC0PY NOT ACTIVE, 1 = ACTIVE 

>0106 ! VERS ! ! VERSION NUMBER 

H — 1 H 

>0108 ! ! ! 
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>010A 

+- 

f 

+ 

-+ 

j 

•*4- 


>010C 

“T*" 

! 

MEMTIC 

! 

^4- 

COUNT BEFORE MEM CNTRL CHECK 

>010E 

“T"" 

1 

SYSTEM ! 

f 

— 4* 

NAME OF SYSTEM 


“T"* 

/ 

/ 

/ 

/ 

/ 

/ 

« 4 » 


>0116 

! 

COMFLG 

J 

-4- 

TO SCHEDULE OR NOT TO SCHEDULE 

>0118 

I 

WCSMAP 

j 

LD MAP TO LOAD WCS (LIMIT) 

>01 lA 

“T — 

j 

FILLOB 

J 

.4. 

(BIAS) 

>01 1C 

1 

FILLOC 

I 

*4- 

RESERVED 

>011E 

“T — 

! 

lOTFLG 

1 

.4- 

SCHEDULER, lOTBID FLAG 

n— Ti T n DT?r\ aitt* c T A wn T MP —s, Ti T n MPTurn 

>0120 

“T 

! 

CLOCNT 

I 

«4- 

rvEjy UUiDXAINJjXlN\jr"*/X)JLJJ INr iDlU 

FILE CLOSES OUTSTANDING 

>0122 

T* 

! 

CPUID 

! 

-• 4 . 

CPU ID 

>0124 

T"“ 

J 

ATTNDV ! 

I 

*• 4 . 

ATTENTION DEVICE NAME 

>0126 

T“ 

! 


i 

~4- 


>0128 

f 

FILLOD ! 

f 

— 4. 

RESERVED 

>012A 

“r*" 

j 


I 

m4- 


>012C 

•r"“ 

1 

CLFLUN ! FILLOE 

I 

STORAGE PLACE FOR LUNO TO .S$CLF 

T?ADPTi' PTTTTTTM TXT TFX?^ HVTT? 

>012E 

f 

UALGFB 

j 

KDVJJ*rUKl-»ri ULirLiUiN IIN Lil!iri DIXJZj 

LARGEST FREE BLOCK OF DYNAMIC MEM 

>0130 

T — 

j 

TILADD 

mm~^ 

j 

SAVE TILINE ADDR FOR POWER UP-MUX 

>0132 

J 

+- 

PWRFLG 

+ 

i 

-+ 

CONTROLLER POWERUP FLAG-MUX 


FLAGS FOR FIELD: SYSOPT #F8 - 

OPTDSK = (X ) - 

OPTMFM = (.X ) - 

OPTCDF = ( . .X ) - 

OPTBLK = (...X ) - 

OPTBSF = ( . . . . X ) - 

OPTEXF = ( X ) - 

OPTACC = ( X ) - 

OPTOSP = ( X ) - 

OPTIPC = ( X ) “ 


SYSGEN OPTIONS WORD(FLAGS BELOW) 

SYSTEM DISK PRESENT 
MINIMUM FILE MANAGEMENT PRESENT 
CREATE/DELETE FILE CAPABILITY 
BLOCKED FILE CAPABILITY 
BLANK SUPPRESSED FILE CAPABILITY 
FILE EXTENSION CAPABILITY 
ACCOUNTING DATA COLLECTED 
OUTPUT SPOOLING 
IPC PRESENT 
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NFDATA 


OPTSEC = ( X ) “ SECURITY 

OPTKIF = ( X.....) “ KIF PRESENT 

OPTEXJ = ( X....) - EXPANDABLE JCA 

OPTRAW = ( X...) - DM READ AFTER WRITE ENABLED 

OPTWCS = ( X..) - 1 = PERF0RMANCE WCS 

OPTPFR = ( X.) - l = POWER FAIL RECOVERY 

= ( X) - RESERVED 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


NFSBWP $-26 >FFF2 

NFSIZE $-TMTOL >134 SIZE OF THIS CSEG 
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************************************************************ 
* * 

* NFJOBC - JOB MANAGER COMMON AREA 11/09/79 * 

* * 
************************************************************ 


THIS COMMON 

SEGMENT 

CONTAINS 

DATA VALUES USED 

BY THE 

JOB 

MANAGER 

• 





* 

+ 

* 



>00 

j 

NXTJID 

I 

NEXT AVAILABLE 

JOB ID 


+ 

+ 

+ 



>02 

I 

FST JID 

I 

BEGINING AVAILABLE JOB ID 


+ 


+ 



>04 

1 

LSTJID 

1 

LAST AVALIBLE ID IN LIST 


+ 

+ 

+ 



>06 

1 

JOBCNT 

! 

NUMBER OF JOBS 

IN SYSTEM 


+ 

+ 

+ 



>08 

i 

JOBLMT 

1 

SYSTEM LIMIT ON 

ACTIVE JOBS 


+ 


+ 



>0A 

I 

JCAMIN 

f 

SIZE OF JCA IN 

BYTES (SMALL) 


+ 

+ 

+ 



>0C 

j 

JCAAVG 

J 

SIZE OF JCA IN 

BYTES (MED) 


+ 

+ 

+ 



>0E 

1 

JCAMAX 

f 

SIZE OF JCA IN 

BYTES (LARGE) 


+ 

+ 

+ 



>10 

I 

JWTQUE 

! 

FOREGROUND JOB 

WAIT LIST 


+ 

H 

+ 



>12 

j 

JOBQ 

I 

JOB MANAGER REQUEST QUEUE 


+ 

1 

+ 



>14 

f 

JOBBCT 

I 

BACKGROUND JOB 

COUNT 


+ 

+ 

+ 



>16 

I 

JOBBLM 

j 

BACKGROUND JOB 

LIMIT 


+ 

+ 

+ 



>18 

I 

JOBBWT 

I 

BACKGROUND JOB 

WAIT LIST 


+ 

+ 

+ 



EQUATES : 






LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 



NFJSIZ $-NXTJID 


>1A CSEG SIZE 
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NFPTR 

**************************** * * ****************************** 

* 





* 

* 

NFPTR 

- SYSTEM 

POINTERS 


09/20/83 * 

* 





* 

************************************************************ 

* THIS COMMON 

SEGMENT 

CONTAINS 

POINTERS 

USED BY MANY PARTS 

* OF 

DNOS. 






* 

+ 

/ 



>00 

1 

TDLHDR 

1 

TIME DELAY LIST HEADER 


+ 


+ 



>02 

j 

WOMQUE 

1 

WAITING 

ON MEMORY QUEUE HEADER 


+ 





>04 

1 

EXTSB 

j 

CURRENTLY EXECUTING TASK 


+ 

+ 




>06 

f 

EXJSB 

I 

EXECUTING TASK JSB ADDRESS 


+ 

H 

+ 



>08 

j 

PDTLST 

i 

START OF 

PDT LIST 


+ 

+ 

+ 



>0A 

I 

LDTLST 

! 

START OF 

LDT LIST 


+ 

+ 




>0C 

1 

JSBLST 

1 

START OF 

JSB LIST 


+ 

+ 

+ 



>0E 

J 

ACTJSB 

I 

START OF 

ACTIVE JSB LIST 


+ 

+ 

+ 



>10 

I 

WOMJSB 

1 

START OF 

JSBS WAITING ON MEMORY 


+ 


+ 



>12 

I 

JCASTR 

j 

START OF 

ALL JCA AREAS 


+ 

+ 

+ 



>14 

J 

MBSSTR 

j 

POINTER 

TO SYSTEM SCB 


+ 

+ 




>16 

! 

PDTSAV 

! 

POINTER 

TO SAVED PDT FOR DSRS 


+ 

+ 

+ 



>18 

1 

MAPSHD 

j 

POINTER 

TO SCHEDULER MAP FILE 


+ 

H 

+ 



>1A 

J 

MAPSV2 

f 

POINTER 

TO SVC SECOND MAP FILE 


+ 

+ 

+ 



>1C 

1 

CURMAP 

j 

POINTER 

TO CURRENT MAP 0 FILE 


+ 

+ 




>1E 

1 

RUTSSB 

I 

POINTER 

TO SSB FOR ROOT 


+ 


+ 



>20 

1 

COMSSB 

! 

SSB ADDR 

OF SYSTEM COMMON 


+ 

+ 

+ 



>22 

! 

SMSTR 

j 

SSB ADDR 

OF FIRST SM SEGMENT 


+ 

+ 

+ 



>24 

{ 

SMEND 

I 

SSB ADDR 

OF LAST SM SEGMENT 


+ 

H 




>26 

J 

FMSTR 

; 

SSB ADDR 

OF FIRST SM SEGMENT 


+ 

+ 

+ 



>28 

f 

FMEND 

1 

SSB ADDR 

OF LAST SM SEGMENT 


+ 

+ 

+ 
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NFPTR 


>2A 

i 

YRPTR 

-L 

f 


“r““ 

( CONTINUED) 

. « -.-I- 

>2C 

T*"' 

1 

SYSTAB 

f 

>2E 

T"— • 

! 

SPATCH 

j 

>30 

! 

IXPTR 

f 

>32 

J 

PCAPTR 

f 

» « «4- 

>34 

“T* 

? 

DTMRAD 

f 

>36 

•r“ 

I 

FILLOO 

I 

>38 

"T — 

f 

FILLOl 

1 

>3A 

1 

FILL02 

! 

>3C 

1 

FILL03 

1 

>3E 

"r“ 

I 

TRCPTR 

f 

>40 

“T — 

I 

BIDREQ 

! 

i. . ..4- 

>42 

f 

EORNKR 

! 

>44 

"T * 

! 

SYSJSB 

i 

— 4. 

>46 

‘T — 

f 

CCBSTR 

1 

>48 

T““ 

f 

SCOTID ! 

1 

mmmmmmA- 

>4A 

"T"" 

j 

MAPISV 

1 

>4C 

1 

MSGQUE 

j 

. — .4- 

>4E 

f 

SOPJSB 

j 

>50 

! 

SYSPDT 

f 

i. «»4- 

>52 

T* — 

f 

ETBPTR 

t 

>54 

I 

PCSPTR 

f 

>56 

f 

PCMPTR 

1 

>58 

! 

PCEPTR 

j 

>5A 

“r — 

J 

OVYTAB 

f 


DNOS System Design Document 


PTR TO YEAR COUNTER (DATE&TIME) 


OVERHEAD PTR FOR TABLE AREA 

START OF PATCH AREA S$$PAT 

ILLEGAL PC 

MUX DEV/INT ENTRY 

ADDRESS OF lODTMR 

RESERVED 

RESERVED 

RESERVED 

RESERVED 


POINTER 

TO 

/12 

TRACE SAVE AREA 

ANCHOR 

FOR 

BID 

REQUESTS 

ANCHOR 

FOR 

EOR 

REQUESTS 

POINTER 

TO 

SYS 

TEM JOB JSB 


START OF THE GLOBAL CCBS 

NFTBID TASK ID AND LUNO 

POINTER TO MAP FILE 1 SAVE 

AREA FOR LEVEL 2 INTERRUPTS 
PTR TO PUT DATA MESSAGES 

SYSTEM OPERATOR JSB ADDRESS 

SYSTEM DISK PDT ADDRESS 

EXPANSION CHASSIS TABLE 

SINGLE DEV/INT ENTRY 

MULTIPLE DEV/INT ENTRY 

EXPANSION CHASSIS ENTRY 

SYSTEM OVERLAY TABLE ADDRESS 
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NFPTR 


>5C ! 

+ 

IDTAB 

j 

>5E ! 

COMPTR 

1 

>60 ! 

BADWP 

t 

>62 ! 

CLOK12 

1 


( CONTINUED) 





>64 ! 

WOTJSB 

1 

>66 ! 

PDSOLD 

1 

>68 ! 

PDSNEW 

j 




EQUATES : 



LABEL 

EQUATE TO 

VALUE 


NFPSIZ $-TDLHDR >6A 


IPL LOADED OVERLAY TABLE ADDR. 
POINTER TO COMM MODULE 
ILLEGAL XOP WORKSPACE 
12 MS CLOCK VECTOR 

TABLE AREA WAIT QUEUE 
PRIORITY DSR SCHEDULER QUE HEAD 
PRIORITY DSR SCHEDULER QUE TAIL 

DESCRIPTION 
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* * * * * * * ****** * * * * * * * * ******** * * ***************************** 

* * 

* PMDATA - GLOBAL DATA VALUES 04/09/81 * 

* FOR PROGRAM MANAGEMENT * 

* * 
************************************************************ 

* THIS COMMON SEGMENT CONTAINS THE PROGRAM MANAGEMENT ERROR 

* RECOVERY SAVE AREA (IN THIS AREA SEGISB THROUGH SEGID2 

* MUST BE CONTIGUOUS), THE COMMON DATA FOR TASK BID 

* ROUTINES, THE COMMON DATA FOR TASK LOADER ROUTINES, THE 

* PROGRAM FILE DIRECTORY DOOR, THE PATHNAME FOR THE SYSTEM 

* PROGRAM FILE, AND THE PATHNAME FOR THE SHARED PROGRAM FILE. 


* + * 


>00 

I 

SEGISB 

! 


H 

+ 


>02 

1 

SEGl ST 

1 


+ 

+ 

+ 

>04 

1 

SEG2SB 

j 


+ 

+ 


>06 

j 

SEG2ST 

I 


+ 

+ 

+ 

>08 

j 

SEG3SB 

j 


+ 


+ 

>0A 

f 

SEG3ST 

! 


+ 

+ 

— — + 

>0C 

! 

CPYLDT 

I 


- 1 - 

+ 

+ 

>0E 

I 

CPYRPB 

1 


+ 

+ 

+ 

>10 

I 

SEGIDl 

I 


+ 

+ 

+ 

>12 

1 

SEGID2 

f 


+ 

+ 

+ 

>14 

f 

ATRSGl 

1 


+ 

+ 

+ 

>16 

j 

ATRSG2 

f 


+ 

+ 

+ 

>18 

! 

ATRTSK 

1 


+ 

+ 

_ — — — + 

>1A 

j 

LENSGl 

j 


+ 

+ 

+ 

>10 

j 

LENSG2 

j 


+ 

+ 

+ 

>1E 

I 

LENTSK 

1 


+ 

+ 

+ 

>20 

I 

LODTSK 

1 


+ 


+ 

>22 

I 

TSKREP 

f 


+ 

+ 

+ 

>24 

t 

JCASSB 

? 


SEGMENT 1 SSB ADDRESS 

SEGMENT 1 SM TABLE SSB ADDRESS 

SEGMENT 2 SSB ADDRESS 

SEGMENT 2 SM TABLE SSB ADDRESS 

SEGMENT 3 SSB ADDRESS 

SEGMENT 3 SM TABLE SSB ADDRESS 

ADDRESS OF LDT COPY 

ADDRESS OF RPB COPY 

*************************** 

SEGMENT INSTALLED ID(2 WORDS) 

ATTRIBUTES OF 1ST ATT. SEG. 
ATTRIBUTES OF 2ND ATT. SEG. 
ATTRIBUTES OF TASK SEG. 

BYTE LENGTH OF 1ST ATT. SEC. 
BYTE LENGTH OF 2ND ATT. SEG. 
BYTE LENGTH OF TASK SEG. 

LOAD ADDRESS OF TASK SEG. 

SSB REPLICATED IN MEMORY FLAG 
SSB FOR JCA OF JOB FOR TASK BID 
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^ 

+ 

-+ 

>26 

! 

JCASMT 

j 


+ 

+ 

-+ 

>28 

1 

SGI BET 

I 


+ 

+ 

“+ 

>2A 

1 

SG2BET 

I 


+ 

-J. 

-+ 

>2C 

f 

SG3BET 

j 


+ 


-+ 

>2E 

j 

LODFLG 

! 


+ 

+ 

-+ 

>30 

i 

ROLDIR 

I 


+ 



>32 

J 

ROLPRS 

! 


+ 


-+ 

>34 

j 

SYSFDP 

! 


+ 

+ 

-+ 

>36 

1 

SYSFMT 

1 


+ 

+ 

“+ 

>38 

f 

SYSFCB 

! 


+ 


-+ 

>3A 

f 

ROLFDP 

1 



+ — 

-+ 

>3C 

I 

ROLFMT 

I 


+ 

+ 

- + 

>3E 

I 

ROLFCB 

{ 


+ 

+ 

— + 

>40 

J 

APLFDP 

f 


-1 

+ 

- + 

>42 

I 

APLFMT 

1 


+ 


-+ 

>44 

1 

APLFCB 

I 


+ 

+ 

— + 

>46 

f 

IMGFDP 

! 


+ 

+ 

- + 

>48 

j 

IMGFMT 

j 


+ 

+ 

- + 

>4A 

f 

IMGFCB 

j 


+ 

+ 

- + 

>4C 

t 

SHRFDP 

I 


+ 


-+ 

>4E 

1 

SHRFMT 

j 


+ 


— + 

>50 

f 

SHRFCB 

1 


+ 

+ 

-+ 

>52 

1 

TIMSPN 

1 


+ 


- + 

>54 

1 


I 


+ . 


— + 

>56 

f 

SYSPN 

f 


+ 

+ 

**• + 

>58 

! SYSPNC ! 

1 


-f 

+ 



PMDATA 

SMT FOR JCA OF JOB FOR TASK BID 
** TASK LOADER COMMON DATA *** 
BEET ADDRESS OF SEGMENT 1 

BEET ADDRESS OF SEGMENT 2 

BEET ADDRESS OF SEGMENT 3 

FLAG FOR LOADED/NOT LOADED SEG 

ROLL DIRECTORY POINTER 

PHYSICAL RECORD LENGTH ROLL FILE 

SYSTEM PF FDP ADDR. 

SYSTEM PF FMT ADDR. 

SYSTEM PF FCB ADDR. 

ROLL FILE FDP ADDR. 

FMT OF ROLL FILE 

FCB OF ROLL FILE 

APPLICATION PF FDP ADDR. 

APPLICATION PF FMT ADDRESS 

APPLICATION PF FCB ADDRESS 

IMAGES PF FDP ADDR. 

IMAGES PF FMT ADDR. 

IMAGES PF FCB ADDR. 

S$SHARED PF FDP ADDR. 

S$SHARED PF FMT ADDR. 

S$SHARED PF FCB ADDR. 

TIME DELAY SVC FOR TASK LOADER 
SPIN ON DISK ERRORS 

PATHNAME SYSTEM UTILITY PROG FL 
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/ / / 

/ / / 

>60 ! SHRPN ! PATHNAME FOR S$SHARED PROG FL 

H — — — — — —-I — — — 

>62 ! WOMPRI ! FILLOO ! PRIORITY OF TASK BEING LOADED 

+ + + RESERVED 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


PMDSIZ $~SEG1SB >64 
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ACC 


22.3 STRUCTURES FROM THE ATABLE DIRECTORY 


*******************:*{**************************************** 
■k k 

* ACCOUNTING RECORD CONTENTS (ACC) 09/09/83 * 

k k 

* LOCATION: SYSTEM TABLE AREA OR DISK * 

******************************* 5 ^* 5 %:^************************* 

* THE ACC DESCRIBES THE FORMAT OF ENTRIES ON THE QUEUE FOR 
PROCESSING BY THE ACCOUNTING FORMATTING TASK (LGACCT). 

WITH THE EXCEPTION OF THE QUEUE LINK, THE ENTRIES ARE 
EXACTLY THE SAME WHEN ON DISK IN THE ACCOUNTING LOG FILE. 
EACH BLOCK TYPE HAS ITS OWN SET OF INFORMATION FOLLOWING 
A STANDARD HEADER. THE EXCEPTION IS IPL (RECORD TYPE 6), 
WHICH USES ONLY THE HEADER INFORMATION. 


>00 


*. 

! 

+ ■ 


ACCLNK 


FIXED PART 

.k 
I 

■ + 


QUEUE LINK 


FIELD DESCRIPTOR VARIANT 


>02 

I 

ACCTYP 

! ACCLEN 

1 

i 

— 4- 

>04 

“r — 

! 

ACCYRD 

I 

>06 

“T"" 

J 

ACCHOU 

! ACCMIN 

JL 

J 

>08 

I 

ACCSEC 

! ACCPRI 

_1_ 

! 

^4. 

>0A 

*1" — 

j 

ACC JID 

-L. 

f 

^4- 






>0C 

k^ 

1 

ACCAID 

-+ 

j 

TYPE 

t 

••4. 


“T — 

/ 

/ 


h ^ 

/ 

/ 

_i_ 

/ 

/ 

— 4- 

>1C 

I 

ACCUID 

f 

i 

««4. 


“T — 

/ 

/ 


/ 

/ 

_L. 

/ 

/ 

.4- 

>24 

! 

ACC JNM 

I 

4- 

1 

— 4- 


/ 


/ 

/ 


RECORD 


RECORD TYPE 
LENGTH OF 
YEAR/DAY 

HOUR 

MINUTE 

SECOND 

PRIORITY 
JOB ID 


1 - JOB INITIALIZATION 


ACCOUNT ID 


USER ID 


JOB NAME 
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/ 

/ 

/ 


+- 

+ 

-+ 




TYP 


*- 


-■k 

>oc 

! 

ACCTID ! ACCTCD 

f 


+- 

+ 

- + 

>0E 

1 

ACCCPU 

j 


+- 


- + 

>10 

! 


1 


+- 

+ 

- + 

>12 

1 

ACCSVC 

! 


+— 


-+ 

>14 

f 


1 


+- 

+ 

-+ 

>16 

I 

ACCIOB 

f 


+- 


-+ 

>18 

1 


1 


+- 

+ 

-+ 

>1A 

f 

ACCMEM 

1 


+- 

+ 

-+ 

>1C 

1 

ACCWAL 

f 


+- 

+ 

-+ 

>1E 

j 


J 


+- 

+ 

-+ 

>20 

1 

ACCIID ! ACCSTN 

J 


+- 

+ 

-+ 

>22 

1 

ACCATR 

! 


+- 

+ 

-+ 

>24 

I 

ACCTNM ! 

! 


+- 

+ 

— + 


/ 

/ 

/ 


/ 

/ 

/ 


+- 

+ 

-+ 




TYP 


* - 


-* 

>0C 

1 

ACC JUD 

f 


+- 

+ 

— + 

>0E 

I 

ACCJSZ 

f 


+- 


-+ . 

>10 

j 

ACC JEX 

j 


+- 


— + 


>12 ! ! 

+ + + 


TYP 


>0C 

* _ 

1 

ACCTPF 

-+- 

1 

* 

ACCDTP ! 

>0E 

+- 

t 

ACCNAM 

-+- 

f 

+ 

1 

>10 

+- 

1 


-+- 

! 

+ 

? 


E 2 - TASK TERMINATION 
TASK ID 

TASK TERM CODE 
TASK CPU TIME (CLOCK TICKS) 

NUMBER SVC'S ISSUED 

NUMBER I/O BYTES TRANFERED 

MAX MEMORY ALLOCATED ( BEETS ) 
WALL CLOCK EXECUTION TIME 

INSTALLED TASK ID 
STATION ID 
TASK ATTRIBUTES 

TASK NAME 

E 3 - JOB TERMINATION 
JCA AREA USED 
JCA TOTAL SIZE 
JOB EXECUTION TIME 

E 4 - DEVICE ENTRY 

DEVICE TYPE FLAGS 
DEVICE TYPE 
DEVICE NAME 
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ACC 


>12 ! 

+ " 

>14 ! 
+• 

>16 ! 


ACCNRQ 


ACCTMU 


NUMBER I/O REQUESTS 


RESERVED-TIME USED ( MI NUTE S ) 


>0C ! 
+■ 


ACCCHR 


TYPE 5 - USER ENTRY 


USER DATA 


>0C ! ACCCOM ! 

+ +. 

/ / 

/ / 

+ +, 


TYPE 7 - COMM ENTRY 


COMM DATA 


>02 ! ACCTXT 

+ 

/ 

/ 

+ 


SINGLE ENTITY VARIANT 


FLAGS FOR FIELD: ACCYRD 


#04 - YEAR/DAY 


ACCYER = (XXXXXXX ) - YEAR (7 BITS) 

ACCDAY = ( XXXXXXXXX) - DAY (9 BITS) 


EQUATES : 


LABEL EQUATE TO VALUE DESCRIPTION 


ACCVNT 
ACTJIT 
ACTTTM 
ACTJTM 
ACTDET 
ACTUET 
ACTIPL 
ACCORD 
ACC JIZ 
ACCTTZ 


JOB INITIALIZATION 
TASK TERMINATION 
JOB TERMINATION 
DEVICE ENTRY 
USER ENTRY 
IPL ENTRY 
END OF OVERHEAD 
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ACC JTZ 

$ 

>14 

ACCDSZ 

$ 

>18 

ACCUSZ 

$ 

>52 

ACCISZ 

$ 

>0C 

ACCCTZ 

$ 

>52 
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ADR 


■k k 

* ALIAS DESCRIPTOR RECORD (ADR) 02/28/79 * 

* k 

* LOCATION; DISK * 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

* THE ADR IS A VARIANT OF A FILE DESCRIPTOR RECORD (FDR), 

* USED TO DESCRIBE AN ALIAS FOR A FILE NAME. THE FIELDS 

* MARKED HERE WITH *** ARE IN THE ADR TEMPLATE TO MAINTAIN 

* COMPATABILITY WITH THE FDR TEMPLATE. 


k 1 k 


>00 

j 

ADRHKC 

1 

>02 

“T*" 

f 

ADRHKV 

! 

>04 

■T" 

I 

ADRFNM ! 

i 


/ 

/ 

/ 

/ 

/ 

/ 

>0C 

“T — 

1 

ADRPSW ! 

f 

>0E 

•T — 

j 

1 

J 

>10 

“1"“ 

I 

ADRFLG 

I 

>12 

j 

FILLOO 

I 

>14 

"T*" 

I 

FILLOl 

I 

>16 

1 

FILL02 

t 

>18 

"T* 

j 

FILL03 

1 

>1A 

T"* 

1 

FILL04 

1 

>1C 

*T*" 

! 

FILL05 

1 

>1E 

f 

ADRRNA 

f 

>20 

•t*— 

I 

+- 

ADRRAF 

+ 

f 


2270512-9701 


HASH 

KEY 

COUNT 

HASH 

KEY 

VALUE 

FILE 

NAME 



PASSWORD 


FLAGS 

(SAME AS 

FDRFLG FLAGS) 

kkk 

PHYSICAL 

RECORD SIZE 


** * 

logical 

RECORD SIZE 


kkk 

PRIMARY 

ALLOCATION SIZE 

kkk 

PRIMARY 

ALLOCATION ADDRESS 

kkk 

secondary allocation 

SIZE 

kkk 

SECONDARY ALLOCATION 

ADDRESS 

RECORD NUMBER 

OF NEXT ADR 


RECORD # OF ACTUAL FDR 



22-31 


Structure Pictures 



BAP 


DNOS System Design Document 




* * 

* BUFFER ADDRESS PACKET (BAP) 9/30/81 * 

* * 

* LOCATION: SYSTEM AREA * 


*********************************:fc:*t************************* 

* THE BAP IS THE ADDRESS OF AN I/O BUFFER WHICH IPC APPENDS 

* TO A BUFFERED I/O REQUEST. 

** BEGINNING PACKED RECORD BAP 


* 1 * 


>00 

I 

+ 

BAPSMT 

1 

+ 

POINTER TO 

SMT SSB 

>02 

j 

+ 

BAPSSB 

1 

+ 

POINTER TO 

BUFFER SEG. SSB 

>04 

j 

+ 

BAPOFF 

j 

+ 

OFFSET TO 

BUFFER WITHIN SEG. 

>06 

SIZE 


** END 

OF PACKED 

RECORD 
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BRO 


************************************************************ 
* * 

* BUFFERED REQUEST OVERHEAD (BRO) 09/09/83 * 

* * 

* LOCATION: SYSTEM TABLE AREA AND JCA * 

************************************************************ 

* THE BRO APPEARS AT THE HEAD OF EACH BUFFERED SVC REQUEST 

* BLOCK WHILE BEING PROCESSED BY DNOS. THE REQUEST IS 

* QUEUED USING THE BROBRO FIELD. 


>FFEE 

*- 

f 

+ 

BROOFL ! BROPRI 

-* 

i 

OVERHEAD FLAGS 

TASK PRIORITY 

OVERHEAD FLAGS PART 2 

ALTERNATE REQUEST ID FOR M/D DSR 
BUFFER BEET ADDRESS 

>FFFO 

"T — 

I 

BR00F2 ! BROAID 

f 

>FFF2 

"T 

I 

BROBBA 

f 

.4. 

>FFF4 

*T“ 

1 

BROLDT 

f 

-4- 

LDT ADDRESS 

>FFF6 

T" — 

I 

BROSID 

f 

—4- 

SESSION/DEVICE ID 

>FFF8 

“r“" 

f 

BRORCB 

j 

— 4- 

REQUESTOR CALL BLOCK ADDRESS 

>FFFA 

"T — 

f 

BROTSB 

j 

^4- 

TSB ADDRESS 

>FFFC 

“T — 

f 

BROJSB 

f 

— 4- 

JSB ADDRESS 

>FFFE 

T 

1 

+ - 

BROBRO 

f 

— + 

QUEUE LINK ADDRESS 


FLAGS FOR FIELD: BROOFL #FFEE 

BRFINR = (X ) - 

BRFARS = (.X ) - 

BRFA5 = (..X ) - 

BRFERN = (...XXXXX ) - 

FLAGS FOR FIELD: BROOF2 #FFF0 

BRFAPI = (X ) - 

BRFRAV = (.X ) ~ 

BRFMRO = (..X ) - 

BRFTID = (...X ) - 

BRFSB = (....X ) - 

BRFSAB = ( X ) - 

BRFDNR = ( X ) - 

= ( X ) - 


- OVERHEAD FLAGS 

INITIATE EVENT REQUEST 
ANOTHER ROUTINE HAS SEEN REQ 
>A5 CALL GIVEN TO IPC (lURL) 
INITIATE REQUEST NUMBER 


- OVERHEAD FLAGS PART 2 

ALTERNATE REQUEST ID SPECIFIED 
REQUEST ACCEPTS EVENT KEYS 
MULTI-RECORD READ/WRITE REQUEST 
TASK ID SPECIFIED IN BROTSB 
SECURITY BYPASS 
SUSPENDING ABORT 
DO NOT RELEASE MEMORY 
UNUSED 


2270512-9701 


22-33 


Structure Pictures 



BRO 


DNOS System Design Document 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

BRFEOR 

BRFA5 

>02 

BRFABT 

BRFSAB 

>05 

BROSIZ 

$-BROOFL 

>12 


DESCRIPTION 


END OF RECORD DONE IMMEDIATELY 
ABORTED OPERATION 
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BTB 


************************************************************ 

* * 

* B - TREE BLOCK (BTB) 09/07/79 * 

* * 

* LOCATION: DISK AND BUFFER SEGMENTS * 

************************************************************ 

* THE BTB DESCRIBES THE OVERHEAD INFORMATION REQUIRED TO SORT 

* THE LOGICAL RECORDS OF A KEY INDEXED FILE. THE BTB RESIDES 

* ON DISK AND IS READ INTO MEMORY WHEN USING A RECORD THAT 

* IT DESCRIBES. 

* 

* SPECIAL FIELD COMMENTS: 


* BTBPPT - IF THIS BLOCK IS BEING USED AS A B-TREE NODE, THIS 

* FIELD IS THE PHYSICAL RECORD NUMBER OF THE 

* PRECEDING NODE ON THE SAME LEVEL (ZERO IF THIS IS 

* THE LEFTMOST NODE). IF THIS BLOCK IS AVAILABLE 

* FOR USE, THIS FIELD POINTS TO THE NEXT AVAILABLE 

* BLOCK. 

* BTBNIE - NUMBER OF POINTER/KEY VALUE PAIRS CURRENTLY 

* CONTAINED IN THIS BLOCK. 

* BTBNEA - THIS BYTE IS ZERO WHEN THE BLOCK IS INITIALIZED 

* BECAUSE OF A B-TREE SPLIT. WHEN THE FIRST ENTRY 

* IS MADE TO THE BLOCK, THIS BYTE CONTAINS THE 

* NUMBER OF ENTRIES IN THE BLOCK THAT ARE GREATER 

* THAN THE NEW ENTRY. 

* BTBNEC - WHEN THE BLOCK IS INITIALIZED DUE TO A B-TREE 

* SPLIT, THIS VALUE IS THE MAXIMUM ENTRIES THAT MAY 

* BE INSERTED INTO THE BLOCK, PLUS ONE. FOR EACH 

* SUBSEQUENT ENTRY TO THIS BLOCK, IF THE NUMBER OF 

* ENTRIES IN THE BLOCK THAT ARE GREATER THAN THE NEW 

* ENTRY EQUALS THE NUMBER IN BTBNEA, BTBNEC IS 

* DECREMENTED BY ONE. WHEN THIS B-TREE BLOCK 

* IS ABOUT TO SPLIT, IF BTBNEC IS ZERO, THE SPLIT IS 

* AT A RATIO OF THE LOWER 90% OF THE ENTRIES ARE IN 

* ONE BLOCK AND THE UPPER 10% IN THE OTHER. OTHERWISE, 

* THE SPLIT IS 50% TO EACH. 

* BTBDBK - IF THIS IS A NON-LEAF NODE, THE FIRST FOUR BYTES 

* CARRY THE RECORD NUMBER OF A BRANCH OR LEAF NODE AND 

* THE LAST TWO BYTES ARE NOT MEANINGFUL. IF THIS IS A 

* LEAF NODE, THE FIRST FOUR BYTES CONTAIN A RECORD NUMBER 

* OF A DATA RECORD AND THE LAST TWO BYTES CONTAIN THE 

* ID OF THE LOGICAL RECORD WITHIN THE DATA RECORD. 

* BTBCMD - THIS FIELD IS USED WHEN THIS RECORD HAS TO BE PRELOGGED. 

* IT IDENTIFIES ALL THE RECORDS PRELOGGED BY THE OPERATION. 

* 1 .* 

>00 ! BTBBLK ! BLOCK NUMBER (2 WORD PHYSICAL 

+ + + RECORD NUMBER OF THIS BTB) 

>02 ! ! 

^ 1 1 - 

>04 ! BTBCMD ! PRELOG NUMBER 


2270512-9701 


22-35 


Structure Pictures 



BTB 


DNOS System Design Document 


+ + + 

>06 ! BTBSR ! SPACE REMAINING (BYTES) IN BTB 

+ + + 

>08 I BTBPPT ! PREDECESSOR OR FREE POINTER 

+ + + 

>0A ! ! 

>0C ! BTBSPT ! SUCCESSOR POINTER 

>0E ! ! 

+ + + 

>10 ! BTBNIE ! BTBLE ! NUMBER OF INDEX ENTRIES 

+ + + leaf entry FLAG(1 = THIS IS A LEAF) 

>12 ! BTBNEA ! BTBNEC ! # OF ENT. AFTER LAST INSERT 

+ + + COUNT OF # SEQ. INSERTS 

>14 ! BTBDBK ! ! B-BLOCK DATA BASE KEY 

+ + + 

>16 ! ! ! 

+ + + 

>18 ! ! ! 

+ + + 

>1A ! BTBKVL ! FIRST POINTER/KEY VALUE PAIR 

+ + + 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


BTBSIZ $ >1C 
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CCB 


■kic'k-k'ick^fk^ck'k’k-k-k'k-k-kifk'k'kicifk’kifk'k’k-kit'k'kitic'kicifkifk’k'k’kieitic^ifkifk-kickifkifk 
* * 

* CHANNEL CONTROL BLOCK (CCB) 06/09/83 * 

* * 

* LOCATION: SYSTEM AREA AND JCA * 

*********************************************************** 

* THE CCB IS THE IN-MEMORY REPRESENTATION OF A CHANNEL. IT 

* RESIDES IN SYSTEM TABLE AREA FOR GLOBAL CHANNELS, IN THE 

* JCA FOR JOB-LOCAL OR TASK-LOCAL CHANNELS. MOST OF THIS 

* STRUCTURE IS BUILT FROM THE CHANNEL DESCRIPTOR RECORD ON 

* DISK. 


* 1 * 

>00 ! CCBCCB I NEXT CCB ADDRESS 

_l — — 

>02 ! CCBFLG ! CHANNEL FLAGS 

^ ^ 1- 

>04 ! CCBTYP ! CCBTF ! DEFAULT RESOURCE TYPE 

+ + + RESOURCE TYPE FLAGS 

>06 ! CCBMXL ! MAXIMUM MESSAGE LENGTH 

H h — — — — + 

>08 ! CCBASG ! CCBOPN ! NUMBER OF CURRENT ASSIGNS 

+ + + NUMBER OF CURRENT OPENS 

>0A ! CCBRPB ! RPB POINTER 

H — h — — — — — — h 

>0C ! CCBTSB ! OWNER TASK TSB ADDRESS 

+ + + 

>0E ! CCBJSB ! OWNER TASK JSB ADDRESS 

+ + + 

>10 ! CCBPFL ! CCBIID ! OWNER TASK PROG FILE LUNO (DPOS/M) 

+ + + OWNER TASK INSTALLED ID 

>12 ! CCBFMT ! OWNER TASK PROGRAM FILE FDP (D) 

— — — — — — — — — H 4- 

>14 ! CCBFCB ! 

+ — — — — H — — h 

>16 ! CCBPBQ ! PENDING BRB QUEUE HEADER 

+ + + 

>18 ! CCBABQ I ALREADY BEING PROCESSED QUEUE HEAD 

+ — — — 1 — — — — H 

>1A ! CCBNAM ! ! CHANNEL NAME LENGTH AND NAME (M). 

+ + + 

/ / / 

/ / / 

+ + + 

FLAGS FOR FIELD: CCBFLG #02 - CHANNEL FLAGS 

CCFSCl = (XX ) - SCOPE - global , JOB , TASK 

* 00=TASK-L0CAL 

* 01=JOB-LOCAL 


2270512-9701 


22-37 


Structure Pictures 



CCB DNOS System Design Document 


* 10=GLOBAL 

* 11=RESERVED 

CCFSHR = (..X ) - SHARED( 1 )/NOT SHARED 

CCFTYP = (...X ) - SYMMETRIC(l) OR MASTER/SLAVE 

CCFASG = (....X ) - OWNER DOES(l) / NOT DO ASSIGN 

CCFABT = ( X ) - OWNER DOES(l) / NOT DO ABORTS 

CCFIOU = ( X ) - OWNER DOES(l) / NOT DO lOU OPS 

= ( X ) - RESERVED (AS IN CREATE CHAN RGB) 

CCFBSY = ( X ).- CCB IS BUSY (IN USE BY IPC TASK) 

CCFOOP = ( X ) - OWNER TASK HAS ISSUED OPEN 

CCFOCL = ( X ) - OWNER TASK HAS CLOSED OR ABORTED 

CCFDED = ( X,...) - CHANNEL IS DEAD 

CCFRCL = ( X...) - NON-SH SYMMETRIC REQUESTER CLOSED 

CCFRAB = ( X..) - NON-SH SYMMETRIC REQUESTER ABORTED 

= ( XX) - RESERVED 

* 

* NOTE: CCBTF=CCBTYP+1 MUST BE TRUE 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


CCFSC2 CCFSCl+l >01 

CCFSCM >C000 >C000 CHANNEL SCOPE MASK 

CCFCHN 13 >0D CHANNEL 

CCFDEV 14 >0E DEVICE 

CCFFIL 15 >0F FILE 

CCFREM >0007 >07 RESOURCE TYPE FLAGS MASK 

CCBDSZ $+8 >22 DPOS/D CCB SIZE 

CCBCSZ $ >4C DPOS/M CCB SIZE 
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CDE 


*************************************************;*{******** 

* 

* COMMAND DEFINITION ENTRY (CDE) 04/02/82 

* 

****************************:*:***************************** 


-h-k 

* 

* 

* 

** 


* THE CDE DESCRIBES ONE ENTRY IN THE COMMAND DEFINITION 

* TABLE FOR A DEVICE. THE ENTRY SHOWS WHAT TASK IS TO BE 

* BID WHEN A KEYBOARD TASK BID IS DONE. 


4r-._ — _ — _ — — — -k 


>00 

I 

CDECHR 

! CDEFLG 

! 


+- 


-+ 

-+ 

>02 

I 

CDELL 

! CDELID 

1 


+- 


-+ 

— + 

>04 

I 

CDEDL 

! CDEDID 

I 


+- 


-+ 

— + 

>06 

! 

CDEPVl 

I 


+- 


-+ 

-+ 

>08 

1 

CDEPV2 

j 


+- 


-+ 

-+ 

>0A 

I 

CDEUID 

j 

1 


+- 


-+ 

— + 


/ 


/ 

/ 


/ 


/ 

/ 


+- 



-+ 


entry identification CHARACTER 
BID FLAGS 

LUNO WITH WHICH TO BID LOGIN 
LOGIN TASK ID 

LUNO TO BID DESTINATION TASK 
DESTINATION TASK ID 
PARAMETER VALUE 1 FOR DEST. TASK 

PARAMETER VALUE 2 FOR DEST. TASK 

DEFAULT USER ID 


FLAGS FOR FIELD: CDEFLG #01 

CDFBCJ = (X ) - 

CDFPEA = ( .X ) - 

CDFELB = ( . .X ) - 

CDFDUI = ( . . .X ) - 

= (....XXXX ) - 

EQUATES : 

LABEL EQUATE TO VALUE 
CDESIZ $ >12 


BID FLAGS 

BID DEST. TASK IN CURRENT JOB 
PASS THE CDE ADDRESS TO LOGIN 
EVEN LOADING BID 
DEFAULT USER ID FOR ELB 
* RESERVED * 


SCRIPTION 


COMMAND DEFINITION ENTRY SIZE 
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* * 

* CHANNEL DESCRIPTOR RECORD (CDR) 08/14/81 * 

* * 

* LOCATION: DISK * 

************************************************************ 

* THE CDR IS THE PERMANENT RECORD OF A CHANNEL. IT IS 

* CARRIED AS AN ALIAS OF THE PROGRAM FILE IN WHICH THE 

* CHANNEL OWNER TASK RESIDES. 


* f. * 


>00 

1 

CDRHKC 

f 

mmJL 

>02 

"T"" 

f 

CDRHKV 

f 

>04 

•r 

I 

CDRNAM ! 

j 

^4. 


“T" 

/ 

/ 

/ 

/ 

/ 

/ 

mmM 

>0C 

“T — 

I 

FILLOO 

I 

^4. 

>0E 

T" — 

I 

FILLOl 

I 

m4- 

>10 

“T — 

I 

CDRFDF 

I 

«i4. 

>12 

"T “ 

f 

CDRFLG ! CDRIID 

f 

.4- 

>14 

T* 

I 

CDRTYP ! CDRTF 

i 

>16 

T* — 

I 

CDRMXL 

i 

m4- 

>18 

“T — 

j 

FILL04 ! 

f 

^4- 

>1A 

T* 

j 

I 

1 

— 4- 

>1C 

! 

! 

f 

••4. 

>1E 

“T — 

f 

CDRRNA 

J 

4- 

>20 

“T"" 

I 

CDRRAF 

J 

.4. 

>22 

•r — 

! 

F I LL 0 5 ! 

I 

•»4- 


T" — 

/ 

/ 

/ 

/ 

/ 

/ 

>90 

“T — 

I 

CDRUID ! 

I 

— 4. 


/ 

/ 

/ 

/ 

/ 

/ 


HASH KEY COUNT 
HASH KEY VALUE 
CHANNEL NAME 

RESERVED 

RESERVED 

FLAGS 

CHANNEL FLAGS 

OWNER TASK INSTALLED ID 
DEFAULT RESOURCE TYPE 
RESOURCE TYPE FLAGS 
MAXIMUM MESSAGE LENGTH 

RESERVED 

RECORD NUMBER OF NEXT CDR OR ADR 
RECORD NUMBER OF ACTUAL FDR 
RESERVED 

USER ID OF CHANNEL CREATOR 
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CDR 


+ + -I- 

>98 ! CDRPSA ! 

H “H — ■"+ 

>9A ! CDRSCG ! ! 

/ / / 

/ / / 

— — — — -f- 

>F8 ! FILL06 ! ! 

+ + + 

/ / / 

/ / / 

+ + + 


PUBLIC SECURITY ATTRIBUTES 
SDT WITH 9 CONTROL GROUPS 

RESERVED 


FLAGS FOR FI 

ELD: CDRFDF #10 

- FLAGS 


= ( 

XXXXXXXXXXXXXXX . ) - 

STANDARD 

FDR FLAGS 

CDFCDR = ( 

X) - 

CDR(l) OR 

NOT(O) 


FLAGS FOR 

FIELD: CDRFLG 

#12 - CHANNEL FLAGS 



CDFSCl = 

(XX 

. . . ) - SCOPE - GLOBAL, 

JOB, 

TASK 



00=TASK-L0CAL 

01=JOB-LOCAL 

10=GL0BAL 

11=RESERVED 




CDFSHR = 

(..X 

. . . ) - SHAREDC 1 ) OR 

NOT 

shared 

CDFTYP = 

(...X 

. . . ) - SYMMETRICC 1 ) 

OR 

MASTER/SLAVE 

CDFASG = 

( X 

. . . ) - OWNER DOES( 1 

) / 

NOT 

DO ASSIGN 

CDFABT = 

( X 

. . . ) - OWNER DOES( 1 

) / 

NOT 

DO ABORTS 

CDFIOU = 

( X 

. . . ) - OWNER DOES ( 1 

) / 

NOT 

DO lOU OPS 

= 

( X 

. . . ) “ RESERVED (AS 

CREATE 

CHANNEL) 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

CDRDPM 

>0080 

>80 

CDRCDM 

>0001 

>01 

CDFSC2 

CDFSCl+1 

>01 

CDFSCM 

>C000 

>C000 

CDFRMl 

>FE00 

>FE00 

CDFCHN 

13 

>0D 

CDFDEV 

14 

>0E 

CDFFIL 

15 

>0F 

CDFRM2 

>FF07 

>FF07 

CDRSIZ 

$ 

>100 

CDRMAX 

>3000 

>3000 


SCRIPTION 


DELETE-PROTECT MASK 
CDR FLAG MASK 

MASK FOR CHANNEL SCOPE 
MASK TO ZERO RESERVED BITS 
CHANNEL 
DEVICE 
FILE 

MASK TO ZERO RESERVED TYPE FLAGS 
MAXIMUM VALUE FOR CDRMXL 
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********************************* * * ************************* 


* 

* CAPABILITIES LIST FILE RECORD (CLR) 01/ 

* 

* LOCATION .S$CLF ON DISK 

* 

*************************************************** 


* 

21/83 * 

* 

* 

* 

********* 


* THE CLR IS USED BY TASKS WHICH ADD, DELETE, OR MODIFY 

* USER IDS OR ACCESS GROUPS. IT HAS 5 VARIANTS: FIR, AGR, 

* UDR, UDO, AND VFY. THE STRUCTURE AND PURPOSE OF EACH VARIANT 

* IS DESCRIBED BELOW. 

* 

* 

* THIS PACKED RECORD IS USED FOR USER ID ENTRIES IN FIR 

* 

** BEGINNING PACKED RECORD UID 



* 

H 



>00 

! FIRID 

1 

1 

+ 

USER ID 


/ 

/ 

/ 



/ 

/ 

/ 



+ 

+ 

+ 


>08 

j 

FIRRN 

1 

USER'S UDR RECORD 


+ 

+ 

+ 


>0A 

SIZE 


** end 

OF PACKED RECORD 


NUMBER 


* 

* THIS PACKED RECORD IS USED FOR ACCESS GROUP ENTRIES IN 

* USER DESCRIPTOR RECORDS (UDR) AND USER DESCRIPTOR OVERFLOW 

* RECORDS (UDO). 

* 

** BEGINNING PACKED RECORD AGE 


ACCESS GROUP ENTRY 

* — _ — — — __ — — * 

>00 ! AGERN ! ACCESS GROUP RECORD NUMBER 

+ + + 

>02 ! AGEOFF ! AGEFLG ! OFFSET INTO ACCESS GROUP RECORD 

+ + + ACCESS GROUP ENTRY FLAGS 

>04 SIZE ** END OF PACKED RECORD 


* 

* THIS PACKED RECORD IS USED FOR ACCESS GROUP NAMES IN 

* ACCESS GROUP RECORDS (AGR) 

* 

** BEGINNING PACKED RECORD AGN 


* + 

>00 ! AGNNAM ! 


* 

I 


ACCESS GROUP NAME 
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CLR 


/ 

/ 

>08 ! 

+ 

>0A SIZE 


/ 

/ 

AGNRSV 


RESERVED 


** END OF PACKED RECORD 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

■k 

* 


** BEGINNING PACKED RECORD CLR 


FILE INFORMATION RECORD (FIR) 

THIS VARIANT IS USED TO STORE USER IDs. IT CONTAINS A 
FLAG WORD, A POINTER TO ANOTHER FIR, AND 5 UID ENTRIES. 
EACH UID ENTRY CONTAINS A USER ID AND THE RECORD NUMBER 
OF ITS USER DESCRIPTOR RECORD (UDR). 


>00 

>02 

>04 

>0E 

>18 

>22 

>2C 


■k. 

I 

+ ■ 
I 

+ ■ 
I 

+ ■ 
/ 
/ 
+ 
I 

+• 

/ 

/ 

+ 

! 

+ 

/ 

/ 

+ 

! 

+ 

/ 

/ 

+ 

j 

+ 

/ 

/ 

+ 


FIRFIR 

FIRRSV 

FIRENT 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


+ 

/ 

/ 

+ 


* 

! 

+ 

f 

+ 

I 

+ 

/ 

/ 

+ 

f 

+ 

/ 

/ 

+ 

! 

+ 

/ 

/ 

+ 

I 

+ 

/ 

/ 

+ 

I 

+ 

/ 

/ 

•+ 


CONTINUATION RECORD NUMBER 
FIR USED/AVAILABLE FLAG 
5 UID ENTRIES 
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* 

* ACCESS GROUP NAME RECORD (AGR) 

* 

* THIS VARIANT IS USED TO STORE ACCESS GROUP NAMES. 

* IT CONTAINS A FLAG WORD, A POINTER TO THE NEXT AGR, AND 

* 5 AGN ENTRIES. EACH AGN ENTRY CONTAINS AN ACCESS GROUP 

* NAME AND A WORD OF UNUSED FLAGS. 

■k 


* 1 * 

>00 ! AGRAGR ! 

+ + + 

>02 ! AGRRSV ! 

>04 ! AGRAGN ! 

+ + + 

/ / / 

/ / / 

+ + + 

>0E ! ! 

/ / / 

/ / / 

+ + + 

>18 ! ! 

+ + + 

/ / / 

/ / / 

+ + + 

>22 ! ! 

+ + + 

/ / / 

/ / / 

+ + + 

>2C ! ! 

+ + + 

/ / / 

/ / / 

-| — — H — — — ^ 

* 


CONTINUATION RECORD NUMBER 
AGR USED/AVAILABLE FLAG 
5 AGN ENTRIES 


* USER DESCRIPTOR RECORD (UDR) 

* 

* THIS VARIANT CONTAINS INFORMATION ASSOCIATED WITH A USER ID. 

* THIS INFORMATION INCLUDES THE ENCRYPTED PASSCODE, DESCRIPTION, 

* AND UP TO 5 ACCESS GROUP ENTRIES. EACH ACCESS GROUP ENTRY 

* CONTAINS A RECORD NUMBER OF AN ACCESS GROUP RECORD (AGR) 

* AND THE OFFSET INTO THE AGR FOR AN ACCESS GROUP NAME OF 

* WHICH THIS USER IS A MEMBER. 

k 


k 


+ 


k 
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>00 

I 

4- — 

UDRUDO 

f 

>02 

I 

UDRRSV 

j 

>04 

I 

1 ^ 

UDRPWD ! 

f 


/ 

/ 

/ 

/ 

/ 

/ 

>0C 

"T*" 

j 

UDRFLG 

^ 

f 

>0E 

I 

UDRDES ! 

1 


/ 

/ 

/ 

/ 

/ 

/ 

>22 

! 

UDRAGE 

1 

>24 

•r — 

f 

f 

f 

>26 

"T — 

! 


1 

>28 

"T — 

! 

f 

f 

>2A 

J 


1 

>2C 

T — 

1 

i 

1 

>2E 

*1““ 

i 


1 

>30 

t 

j 

j 

>32 

1 


1 

>34 

T — 

I 

+ - 

1 

1 


POINTER TO OVERFLOW 
UDR USED/AVAILABLE FLAG 
ENCRYPTED PASSCODE 

UDR FLAG WORD 
DESCRIPTION OF USER 

5 ACCESS GROUP ENTRIES (AGE) 


* USER DESCRIPTOR OVERFLOW RECORD (UDO) 

■k 


* THIS VARIANT IS USED ONLY USED IN THE CASE THAT A USER IS 

* A MEMBER OF MORE ACCESS GROUPS THAN WILL FIT IN HIS UDR. 

* IT CONTAINS UP TO 12 ACCESS GROUP ENTRIES. 

* 



* 

+ 

* 

>00 

f 

UDOUDO 

1 


+ 

+ 

+ 

>02 

J 

UDORSV 

1 


+ 

+ 

h 

>04 

J 

UDOFIL 

1 


H 

+ 

+ 

>06 

I 

UDOAGE 

j 


POINTER TO NEXT UDO 
UDO USED/ AVAILABLE FLAG 
NOT USED 

12 ACCESS GROUP ENTRIES (AGE) 
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>08 

+ 

f 

f 

+ 

f 

>0A 

f 


f 

>0C 

“T 

i 

1 

1 

>0E 

I 


1 

>10 

I 

1 

! 

>12 

-r i- «« 

f 


! 

>14 

I 

1 

I 

>16 

! 


j 

>18 

r " 

j 

f 

f 

>1A 

j 


I 

>1C 

f 

I 

I 

>1E 

I 


I 

>20 

“r 

! 

I 

I 

>22 

-r 

f 


! 

>24 

! 

1 

f 

>26 

f 

-t- ^ 


! 

>28 

t 

1 

f 

>2A 

1 


f 

>2C 

f 

_L. 

I 

f 

>2E 

i 


! 

>30 

f 

J. 

1 

f 

>32 

1 


j 

>34 

I 

+ 

1 

f 

+ 


* 

* VERIFICATION RECORD (VFY) 

* 

* THIS VARIANT IS USED BY THE SYSTEM RESTART TASK TO VERIFY 

* THE EXISTENCE OF .S$CLF. IT IS ALSO USED BY TASKS WHICH 

* CREATE AND MODIFY ACCESS GROUPS BECAUSE IT CONTAINS A 
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* POINTER TO THE FIRST ACCESS GROUP RECORD. 

* 


>00 


>08 

>0A 


>36 


* 

I 

+ 

/ 

/ 

+ 

! 

+ 

I 

+ 

/ 

/ 




VFYNAM ! 


/ 

/ 

VFYBLK 
VFYFIL ! 


/ 

/ 


+ + 

SIZE 


* 

j 

/ 

/ 

j 

+ 

I 

/ 

/ 

+ 

** END 


NAME OF S$CLF 


POINTER TO FIRST AGRBLK 

NOT USED, INITIALIZED TO BLANKS 


OF PACKED RECORD 


FLAGS FOR FIELD: AGEFLG #03 

AGELDR = (X ) 

AGEFCG = ( .X ) 

FLAGS FOR FIELD: FIRRSV #02 

FIRFRE = (X ) 

FLAGS FOR FIELD: AGRRSV #02 

AGRFRE = (X ) 

FLAGS FOR FIELD: UDRRSV #02 

UDRFRE = (X ) 

FLAGS FOR FIELD: UDRFLG #0C 

UDRPVL = (XXXXX ) 

UDRAGC = ( XXXXXXXXXXX) 

FLAGS FOR FIELD: UDORSV #02 

UDOFRE = ( X ) 


ACCESS GROUP ENTRY FLAGS 

TRUE=USER IS LEADER OF ACCESS GROUP 
TRUE=FILE CREATION ACCESS GROUP 

FIR USED/AVAILABLE FLAG 
TRUE=AVAILABLE RECORD 

AGR USED/AVAILABLE FLAG 
TRUE=AVAILABLE RECORD 

UDR USED/AVAILABLE FLAG 
TRUE=AVAILABLE RECORD 

UDR FLAG WORD 

USER PRIVELEDGE LEVEL 
ACCESS GROUP COUNT 

UDO USED/AVAILABLE FLAG 
TRUE=AVAILABLE ENTRY 
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EQUATES : 


LABEL 

EQUATE TO 

VALUE 

FIR 

$ 

>00 

AGR 

$ 

>00 

UDR 

$ 

>00 

UDO 

$ 

>00 

VFY 

$ 

>00 

FIRSIZ 

$ 

>36 

AGRSIZ 

$ 

>36 

UDRSIZ 

$ 

>36 

UDOSIZ 

$ 

>36 

VFYSIZ 

$ 

>36 


DESCRIPTION 
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* * 

* DIOU DATA BASE DEFINITION (DDE) 12/01/81* 

* * 

* LOCATION: DIOU NAME MANAGER SEGMENTS AND * 

* RELATIVE RECORD FILE * 

** BEGINNING PACKED RECORD DDE 

* DEVICE NAMES 

* DEVICE NUMBERS 

* 

* 

* 


RELATIVE RECORD FILE RECORDS 



*_ 

+ 

-* 

>00 

I 

DDBORl 

? 


+- 


-+ 

>02 

I 

DDBORT 

f 


+- 


-+ 

>04 

1 

DDBODT 

DDBOCT 



+- 


— + 

>06 

f 

DDBOCE 

f 


+- 

+ — 

— + 

>08 

1 

DDBOWT 

DDB0R2 

f 


+- 


-+ 



*- 



>00 

j 

DDBINU 

1 


+— 


-+ 

>02 

1 

DDBIRR 

1 


+- 


-+ 

>04 

I 

DDBIPA 

1 


+- 

+ 

-+ 

>06 

! 

DDBIFI 

f 


+- 

4- 

- + 

>08 

f 

DDB1F2 

f 


+- 


-+ 

>0A 

i 

DDBILC 

DDBITC 

1 


+- 


-+ 

>0C 

j 

DDBIOJ 

t 


+- 


-+ 

>0E 

j 

DDBILP 

1 


+- 



>10 

! 

DDBIRP 

1 


+ - 


— + 


*- 


-* 

>00 

j 

DDB2R1 

DDB2NF 

1 


+ 4 - + 


*RESERVED 

*RESOURCE TYPE 

*DEVICE TYPE 
*CDT NUMBER 
*CDE MASK 

*WRITE TASK ID 
*RESERVED 

*DEVICE NUMBER 

*RELATIVE RECORD NUMBER 

*PDT ADDRESS 

*FLAGS 

*FLAGS 

*ASSIGNED LUNO COUNT 

*ATTACHED TASK COUNT 
*OWNER JOB 

*LOCKED PARAMETER LIST ANCHOR 
*RPB ANCHOR 

*RESERVED 

*DEVICE NAME FILE 
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>02 

J 

DDB2RR 

1 

m-L 

>04 

T“ 

I 

DDB2NA 

T 

i 

i»4- 



"T*" 





A— 



— A 

>00 

1 

OSPPRM 

“T W. i_i -i 

! OSPSTR 

j 

«4- 

>02 

“T* 

f 

OSPOFF 

! OSPLEN 

j 


“T* 


“T lUl 4^ ^ .li 






— is 

>00 

f 

STRES 

r *“ 

! STID 

_L 

j 

•m4- 

>02 

T** 

! 

STFNAS 

f 

>04 

“T — 

f 

STFNUS 

-1- 

I 

*4- 

>06 

I 

FILLOO 

! 

1 

m-4- 


/ 

/ 


-r mi ^ 

/ 

/ 

/ 

/ 
— 4- 

>1A 

j 

STPTNM 

“T -u -it m. 

I 

j 

«m4-. 


/ 

/ 

+- 


/ 

/ 

- + 

/ 

/ 

-+ 


>2C SIZE ** END 


*RELATIVE RECORD NUMBER 
^DEVICE NAME 


*PARAMETER NUMBER 

^STRUCTURE IDENTIFIER 
^OFFSET INTO STRUCTURE 
*LENGTH OF PARAMETER 


*RESERVED 

*SESSION identifier 
*FIRST NAME SEGMENT RUN ID 

*FIRST NUMBER SEGMENT RUN ID 

*REST OF THE RUN IDS 


*PATHNAME OF SYSTEM 


OF PACKED RECORD 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


RELREC 

0 

>00 

*RELATIVE RECORD FILE 


NAMSEG 

1 

>01 

*NAME MANAGER SEGMENTS 

ordered 

NUMSEG 

2 

>02 

*NAME MANAGER SEGMENTS 

ORDERED 

DSKPDT 

3 

>03 

*DISK PDT 


DDBOVL 

$ 

>0A 

*BEGINNING OF VARIABLE 

LENGTH 

DDBOPD 

$ 

>0A 

*PRINT DEVICE NAME 


DDBOVD 

$ 

>0A 

*VIRTUAL DEVICE SERVER 


DDBOUP 

$ 

>0A 

*USER PARAMETERS 


DDBNOS 

$ 

>0A 

*NON O.S. parameters 


DDBISZ 

$ 

>12 

*SIZE 


DDFIDS 

>1800 

>1800 

*DEVICE STATE MASK 
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DIA 


* * 

* DIAGNOSTIC STATUS (DIA) 05/16/79 * 

* * 

* LOCATION: JCA * 

*********************************************************** 

* THE DIA DESCRIBES A TASK WHICH IS TERMINATING ABNORMALLY. 

* IT IS USED TO PROVIDE END ACTION STATUS TO A TASK AND TO 

* BUILD A TERMINATION MESSAGE FOR THE SYSTEM LOG. 



*- 


-* 

>00 

! 

DIAEC ! FILLOO 

j 


+- 


-+ 

>02 

j 

DIAWP 

i 


+- 


— h 

>04 

1 

DIAPC 

j 


+- 


-+ 

>06 

I 

DIAST 

j 


+- 


-+ 

>08 

f 

DIALMl 

f 


+- 

+ 

-+ 

>0A 

1 

DIALM2 

J 


+— 


-+ 


EQUATES ; 

LABEL EQUATE TO VALUE 


DIASIZ $ >0C 


TASK ERROR CODE 
RESERVED 

TASK WORKSPACE POINTER 
TASK PROGRAM COUNTER 
TASK STATUS 

END ACTION TIME LIMIT(1ST WORD) 
(SECOND WORD) 

DESCRIPTION 
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* * 

* DISK INFORMATION TABLE (DIT) 09/09/83 * 

* * 
icii-k-kit:k4c-k'ffkifk-k'k‘ic-k-k'/fkifk-ii-kifkifkifk:kitic-k^ifkic4t*'k-kicic*icieieiciticitic'ie-k'k:k4fk'k-kifk:k*4tieicifk 

* THIS TEMPLATE IS USED TO DESCRIBE EACH ENTRY IN THE DITDAT TABLE 

* USED BY THE DISK VOLUME UTILITIES. THERE IS ONE ENTRY IN DITDAT 

* FOR EACH DISK TYPE THAT IS SUPPORTED BY DNOS. 


* 


** BEGINNING PACKED RECORD DIT 



* - 

+ 

* 


>00 

I 

DITSRl 

! 

DISK STORE REGISTERS 1 




+ 


>02 

f 

DITSR2 

j 

DISK STORE REGISTERS 2 


+- 

+ 

— — — — + 


>04 

i 

DITSR3 

I 

DISK STORE REGISTERS 3 


+- 

+ 

* + 


>06 

f 

DITFLG 

I 

DISK INFORMATION FLAGS 


+- 


+ 


>08 

1 

DITPRL 

i 

PHYSICAL RECORD LENGTH-DEFAULT 


+- 

+ 

+ 


>0A 

j 

DITNVE 

! 

NUMBER VCATALOG ENTRI ES-DEFAULT 


+- 

+ 

+ 


>0C 

f 

DITNAM ! 

i 

DISK NAME 


+- 

+ 

“ — " + 



/ 

/ 

/ 



/ 

/ 

/ 



+- 


1- 


>1C 

1 

DITNSC ! DITSCM ! 

NUMBER SPARE CYLINDERS 


+- 

+ 

+ 

SPARE cylinders FOR MAPPING 

>1E 

j 

DITHIF 

1 

HARDWARE INTERLEAVE FACTOR-DEFAULT 


+- 

+ 

— — — — + 


>20 

I 

DITTPP 

1 

TEST PATTERNS POINTER 


+- 

+ 

+ 


>22 

1 

DITDSP 

t 

DIAGNOSTIC SECTORS POINTER 


+- 

+ 

+ 


>24 

J 

DITNDS ! FILL03 ! 

NUMBER OF DIAGNOSTIC SECTORS 


+- 

+ 

+ 

SPARE BYTE - NOT USED 

>26 

I 

DITRTF 

1 

READ TYPES FLAGS FOR SURFACE ANALYSI 


+- 


+ 


>28 

j 

DITCRL 

I 

DISK CONTROLLER REVISION LEVEL 


+- 

+ 

+ 


>2A 

I 

FILL05 

I 

SPARE - NOT USED 


+- 

+ 

+ 


>2C 

SIZE 

** END 

OF PACKED RECORD 
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DOR 


itikit*ifkifk:k-k-k-k-k-kic*-k:fck-k'k-k'k-kifkik‘k-k-k:kic-kit:k'kicic‘k-k-k-k-k**-k-kififkickitifk:kici(4eii 
* * 

* DIRECTORY OVERHEAD RECORD (DOR) 01/31/79 * 

* * 

* LOCATION: DISK * 

********:*;*************************************************** 

* THE DOR IS THE FIRST RECORD (RECORD 0) OF A DIRECTORY FILE 

* AND SHOWS THE MAXIMUM SIZE AND CURRENT USE OF A DIRECTORY. 


_ — _ — — . — — — — . 4 ; 

>00 ! DORNRC ! 

+ + + 

>02 ! DORNFL ! 

>04 ! DORNAR ! 

+ + + 

>06 ! DORTFC ! 

+ + + 

>08 ! DORDNM ! ! 

+ + + 

/ / / 

/ / / 

>10 ! DORLVL ! 

+ + + 

>12 ! DORPNM ! ! 

4 - + + 

/ / / 

/ / / 

+ 4 - 4 - 

>1A ! DORPRS ! 

+ + + 


EQUATES : 

LABEL EQUATE TO VALUE 


DORSIZ $ >1C 


# RECORDS IN DIRECTORY 

# FILES CURRENTLY IN DIRECTORY 

# OF AVAILABLE RECORDS 
NUMBER OF TEMPORARY FILES 
DIRECTORY FILE NAME 

LEVEL # OF DIRECTORY 
NAME OF PARENT FILE 

DEFAULT PHYSICAL RECORD LENGTH 
(USED FOR FILE CREATION) 

DESCRIPTION 
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* * 

* DISK PDT EXTENSION (DPD) 01/17/83 * 

* * 

* LOCATION: SYSTEM TABLE AREA * 

*************ifc***************:fe****************************** 

* THE DPD APPEARS AFTER THE STANDARD PDT INFORMATION FOR A 

* DISK DEVICE. IT IS USED AS A WORK AREA BY THE DSR AND BY 

* THE DISK MANAGER TASK. 


>00 

! 

+ 

DPDTIL ! 

1 


T** 

/ 

/ 

/ 

/ 

/ 

/ 

^4. 

>10 

f 

DPDSLG ! 

I 


•f" 

/ 

/ 

/ 

/ 

••*1" 

/ 

/ 

>20 

*T* 

! 

DPDECT 

I 

>22 

I 

DPDWTK 

f 

>24 

I 

DPDSTK ! DPDOHD 

*""1" 

! 

>26 

•T"*“ 

1 

DPDCYL 

"•"T 

f 

>28 

T — 

I 

DPDSRD ! DPDRTK 

•“T 

1 

>2A 

“T — 

I 

DPDWRD 

“■T 

1 

>2C 

j 

DPDILF 

*“r 

f 

>2E 

“r““ 

f 

DPDMAD 

“T* 

f 

>30 

"T** 

I 

DPDSAD 

I 

>32 

•T"* 

1 

DPDDRS 

! 

>34 

“T* 

f 

DPDFLG 

•■‘T 

! 

>36 

"T" 

I 

DPDIBF ! 

— “T 

j 

>38 

I 


1 

>3A 

"r““ 

I 


? 

>3C 

T — 

t 

+ - 

DPDFMS 

+ 

— T 

1 

- + 


TILINE IMAGE 

TILINE IMAGE FOR SYSTEM LOG 

TILINE UNIT ERROR COUNT 

WORDS PER TRACK 

SECTORS PER TRACK 

OVERHEAD PER RECORD 
heads & CYLINDERS 

SECTORS PER RECORD 
RECORDS PER TRACK 
WORDS PER RECORD 

interleaving factor 

MAX NUMBER OF ADUS ON DISK 
SECTORS PER ADU 
DEFAULT PHYSICAL RECORD SIZE 
FLAGS 

initialization buffer 

VCAT FD SPECIAL AREA SSB ADDRESS 
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DPD 


>3E ! DPDFDB ! POINTER TO VCATALOG FOB 

+ + 

>40 ! DPDPBM ! DISK MANAGER TABLE/BUFFER ADDR 

+ + + (NON-ZERO = DISK INSTALLED) 

>42 ! DPDVNM ! ! VOLUME NAME 

+ + + 

/ / / 

/ / / 

>4A ! DPDTFL ! ! TEMPORARY FILE NAME SEED 

+ + + 

/ / / 

/ / / 

>52 ! DPDIVD ! INSTALLED VOLUME CREATION DATE 

+ + + 

>54 ! DPDIVT ! INSTALLED VOLUME CREATION TIME 

FLAGS FOR FIELD: DPDFLG #34 - FLAGS 
= (X ) - 

DPFRAW = (.X ) - DISK READ AFTER WRITE 

DPFBRW = (..X ) - BIT MAP READ AFTER WRITE 

DPFRST = (...X ) - RESTORE FLAG 

DPFSTR = (. ...X ....•) - STORE REGISTER FLAG (1= STORE 

* REG COMMAND WAS ISSUED BY DSR 

* TO DETERMINE IF >1B ERROR IS 

* AN UNSAFE OR MEDIA CHANGE 

DPFODI = ( X .....) - 1 = ONLINE DIAGNOSTIC REQUEST 

DPFWRP = ( X ) - SOFTWARE WRITE PROTECT FLAG 

DPFBLF = ( X ) - BUFFER LOCK FLAG. 

* 1 = THIS DRIVE LOCKED THE 

* NON-RE ENTRANT BUFFER USED 

* BY MEDIA CHANGE VALIDATION 

* PROCESS. 

DPFDTN = ( X ) - DIRECT TILINE I/O FLAG 

= ( XXXXXXX) - 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


DPDSIZ $ >56 DISK PDT + EXTENSION SIZE 
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*************************************ifc************** ******* 


* * 

* DUTIL DEVICE PARAMETERS (DPR) 10/04/83 * 

* * 

* CHANGES TO THIS TEMPLATE REQUIRE CORRESPONDING * 

* CHANGES TO THE PASCAL TEMPLATE "DPRPAS". * 


*********************************************************** 

* THE DPR TEMPLATE DESCRIBES THE DEVICE PARAMETERS MANAGED 

* BY THE DEVICE I/O UTILITY (DUTIL), IT INCLUDES PARAMETERS 

* IN THE FOLLOWING RANGES: 

* 

* PARAMETER RANGE PARAMETER USAGE 

* 

* >01 - >5F OPERATING SYSTEM RESERVED 

* >60 - >FF NOT SUPPORTED 

* 

* IN THE FIELD COMMENTS, RO INDICATES THAT A PARAMETER IS 

* READ ONLY AND CANNOT BE MODIFIED. 

* 

* SPECIAL FIELD COMMENTS; 

* DPRNAM - ONE TO EIGHT ALPHANUMERIC CHARACTERS WITH A LETTER 

* AS THE FIRST CHARACTER. 

* DPRNUM - ONE WORD NUMBER BETWEEN >0001 AND >07FF, EXCLUDING 

* 100 THROUGH 255 (>64 THROUGH >FF). 

* DPRTYP « LIKE THE PDTTYP FIELD. ON AN ASSIGN LUNO , THE VALUE 

* OF THIS FIELD IS PUT INTO THE LDTTYP FIELD OF THE 

* LDT AND IS RETURNED TO THE CALL BLOCK IN THE UPPER 

* BYTE OF THE DATA BUFFER FIELD. 

* DPRJOB - JSB OF THE FIRST JOB TO ASSIGN A LUNO TO A TERMINAL. 

* 

* EQUATES FOR DPRFLG 

* 00 - ONLINE 

* 01 - OFFLINE 

* 10 - DIAGNOSTIC 

* 11 ” SPOOLER 

* EQUATE FOR DPRDSF 

* EQUATES FOR DPRDTF - DEVICE TYPE FLAGS 


Structure Pictures 


22-56 


2270512-9701 



DNOS System Design Document 


DUS 


****************************** 

* 

* DEVICE UTILITY SESSION TABLE 

* 

* LOCATION: IN DUDATA 

* 

****************************** 


* 1 ..... — ...* 

>00 ! DUSRES ! DUSLUN ! 

>02 ! DUSNAM ! 

+ + + 

>04 ! ! 

+ + + 

>06 ! ! 

-I — ....-f. 

>08 ! DUSVOL ! ! 

+ + + 

/ / / 

/ / / 

+ + + 

>10 ! DUSSYS ! ! 

+ + + 

/ / / 

/ / / 

+ + + 

>18 ! DUSDTB ! ! 

+ + + 

/ / / 

/ / / 

+— — — — — — — I ..... — j. 


***************************** 

* 

(DUS) 09/09/83 * 

* 

* 

* 

***************************** 


RESERVED AT PRESENT 

LUNO OF ACTIVE FILE 
NAME MANAGER SEGMENT IDS 


VOLUME NAME OF SYSTEM DISK 


SYSTEM NAME 


TABLE OF device TYPE COUNTS 


EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


MAXSEG 3 
DUSSIZ $ 


>03 MAXIMUM NUMBER OF SEGMENTS 
>26 
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* 

* FILE DESCRIPTOR PACKET (FDP) 06/22/81 

* 

* LOCATION: ALWAYS A SUB-STRUCTURE 

********************************************************** 


** 

* 

* 

* 

* 

** 


THE FDP IS 
(FCB), THE 
WHICH THE 

A TWO WORD 
FIRST WORD 
SECOND WORD 

ADDRESS 
IS THE 
IS THE 

OF A FILE CONTROL 
SSB ADDRESS OF THE 
LOGICAL ADDRESS. 

BLOCK 

TABLE IN 

* _ 



>— * 



>00 ! 

FDPFMT 


! 

- -L. 

SSB ADDRESS OF FILE MANAGER TABLE 

4i. M . 

>02 ! 

+ 

FDPFCB 


I 

--+ 

FCB ADDRESS 



EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


FDPSIZ 


>04 


Structure 
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FDR 




* 


* 


* FILE DESCRIPTION RECORD (FDR) 

* 


09/09/83 * 

* 


* LOCATION: DISK * 

************************************* 5 *:***:^****************** 

* THE FDR IS THE DISK-RESIDENT FILE DESCRIPTOR TELLING WHERE 

* THE FILE RESIDES, ITS CHARACTERISTICS, AND SECURITY DATA. 

* SECURITY DATA IS STORED IN ACCESS CONTROL ENTRIES (ACEs) 

* 


** BEGINNING PACKED RECORD ACE 



* 

+ 



>00 

! ACEAGN ! 

1 

ACCESS GROUP NAME 


+ 

+ 

+ 



/ 

/ 

/ 



/ 

/ 

/ 



+ 

+ 

+ 


>08 

I 

ACEFLG 

1 

FLAGS 


+ 

+ 

+ 


>0A 

SIZE 


** END 

OF PACKED RECORD 


■k ^ k 


>00 

! 

FDRHKC 

1 


+- 

+ 

+ 

>02 

I 

FDRHKV 

f 


+- 

+ 

+ 

>04 

f 

FDRFNM ! 

1 


+- 

+ 

+ 


/ 

/ 

/ 


/ 

/ 

/ 


+- 

+ 

— — — -4- 

>0C 

1 

FDRRSV ! 

j 


+- 


+ 

>0E 

I 

FDRFLl 

1 


+- 

+ 

+ 

>10 

j 

FDRFLG 

! 


+- 

+ 

— — — — + 

>12 

! 

FDRPRS 

! 


+- 

+ 

— * — + 

>14 

f 

FDRLRS 

! 


+- 


— — — —4- 

>16 

j 

FDRPAS 

I 


+- 

+ 

+ 

>18 

f 

FDRPAA 

t 


+- 

+ 

+ 

> lA 

? 

FDRSAS 

1 


+- 

+ 

1- 


HASH 

KEY 

COUNT 

HASH 

KEY 

VALUE 

FILE 

NAME 



RESERVED 
FLAGS WORD 1 
FLAGS WORD 2 
PHYSICAL RECORD SIZE 
LOGICAL RECORD SIZE 
PRIMARY ALLOCATION SIZE 
PRIMARY ALLOCATION ADDRESS 
SECONDARY ALLOCATION SIZE 
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>1C 

! 

FDRSAA 

1 

>1E 

! 

FDRRFA 

f 

«»4. 

>20 

"T — 

1 

FDREOM 

j 

-l_ 

I 

— 4. 

>22 

“T — 

! 


f 

f 

>24 

“r — 

! 

FDRBKM 

T" 

f 

-L. ^ » 

! 

^4. 

>26 

•r* 

! 


f 

j 

*4- 

>28 

*T* 

! 

FDROFM 

1 

«4. 

>2A 

“r** 

1 

FDRFBQ 

f 

-L 

j 

••4- 

>2C 

i 


! 

1 

•»4. 

>2E 

T“ 

j 

FDRBTR 

_l_ 

J 

>30 

T* — 

j 

FDREBQ 

1 

j 

>32 

T" 

! 


J, «... w * 

j 

-1_ 

! 

-4- 

>34 

T" — 

I 

FDRKDR 

-1_ 

1 

— 4. 

>36 

"T — 

I 

FDRUD 

I 

1 

-•4. 

>38 

"r"“ 

J 


j 

I 

«.4. 

>3A 

"T" 

1 


■r * 

1 

_L 

! 

*•4- 

>3C 

“r“ 

j 

FDRCD 

! 

j 

..4. 

>3E 

I 


\ " ' _L ^ U* 

f 

f 

^4. 

>40 

I 


J 

i 

^4. 

>42 

1 

FDRAPB 

! FDRBPA 

f 

•*4- 

>44 

“T — 

I 

FDRMRS 

_L 

f 

— 4- 

>46 

I 

FDRSAT 

I 

j 

^ 4- 


/ 

/ 


/ 

/ 

/ 

/ 

— 4- 

>86 

I 

FDRRES 

; 

j 

^4- 


”r — 

/ 

/ 


r “ 

/ 

/ 

/ 

/ 

«4- 

>90 

“r— 

t 

FDRUID 

f 

I 


OFFSET OF SCONDARY TABLE 
RECORD NUMBER OF FIRST ALIAS 
END OF MEDIUM RECORD NUMBER 

END OF MEDIUM BLOCK NUMBER 

END OF MEDIUM OFFSET/ 

PRELOG NUMBER FOR KIF 
FREE BLOCK QUEUE HEAD 

B-TREE ROOTS BLOCK # 

EMPTY BLOCK QUEUE 

KEY DESCRIPTIONS RECORD # 
LAST UPDATE DATE 

CREATION DATE 

ADU'S PER BLOCK 
BLOCKS PER ADU 
MINIMUM KIF RECORD SIZE 

SECONDARY ALLOCATION TABLE 

RESERVED 

USER ID OF FILE CREATOR 
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FDR 


+ + + 

/ / / 

/ / / 

+“ — — — — — — — — 1 -. 

>98 ! FDRPSA ! 

H — — — — — — — — — — — — — — 

>9A ! FDRACE ! 

+ + + 

/ / / 

/ / / 

+ + + 

>A4 ! ! 

+ + + 

/ / / 

/ / / 

+ + + 

> AE ! I 

+ + + 

/ / / 

/ / / 

— — — — — — 4-— —— — — . — ---.j. 

>B 8 ! ! 

— — — — — — — — — — — — — 

/ / / 

/ / / 

— — — — — — — — ——-I- 

>C2 ! ! 

+ + + 

/ / / 

/ / / 

H — — — — — — — — — — — — ———|- 

> CC ! ! 

— — — — — — — — — 4. 

/ / / 

/ / / 

4.— — — — — — — — — — — — — — — -I- 

>D 6 ! ! 

/ / / 

/ / / 

4- + + 

>E0 ! ! 

4 . 4 . 4 . 

/ / / 

/ / / 

4- + + 

>EA ! ! 

4 ._ — — — — — — — — — 4 . — — — — — — — — — — 4 . 

/ / / 

/ / / 

4- + + 

>F4 ! FDRFIL ! ! 

4- + + 


PUBLIC SECURITY ATTRIBUTES 
9 ACCESS CONTROL ENTRIES 


NOT USED 
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/ 

/ 

/ 



/ 

/ 

/ 



+ 

1 

+ 



FLAGS FOR 

FIELD: ACEFLG 

#08 - FLAGS 

ACERDF = 

(X 

....) - READ ACCESS FLAG 

ACEWRF = 

( .X 

....) - WRITE ACCESS FLAG 

ACEDLF = 

(..X 

....) - DELETE ACCESS FLAG 

ACEEXF = 

(...X 

....) - EXECUTE ACCESS FLAG 

ACECTF = 

( X 

....) - CONTROL ACCESS FLAG 


FLAGS FOR FIELD: FDRFLl #OE - FLAGS WORD 1 

FDFSEC = (X ) - FILE SECURED BIT 

= ( .XXXXXXXXXXXXXXX) - RESERVED 

FLAGS FOR FIELD: FDRFLG #10 - FLAGS WORD 2 


FDFFU = (XX ) - FILE USAGE BITS 

FDFFMT = (..XX ) - FILE FORMAT BITS 

FDFALL = (....X ) - EXTENDABLE FILE FLAG 

FDFFT = ( XX ) - FILE TYPE BITS 

FDFWPB = ( X ) - WRITE PROTECT BIT 

FDFDPB = ( X ) - DELETE PROTECT BIT 

FDFTMP = ( X ) - TEMPORARY FILE FLAG 

FDFBLB = ( X ) - BLOCKED FILE FLAG 

FDFALI = ( X....) - ALIAS FLAG BIT 

FDFFWT = ( X...) - FORCED WRITE/PARTIAL LOGGING 

= ( XX.) - RESERVED 

FDFCDR = ( X) - RECORD IS CDR 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


FDFFUM >C000 >C000 FILE USAGE MASK 

FDFFMM >3000 >3000 FILE FORMAT BITS MASK 

FDFFTM >0600 >600 FILE TYPE MASK 

FDFUPM >0180 >180 WRITE AND DELETE PROTECT MASK 

FDRMNT $ >2A MAX NUMBER OF TASKS IN PF 

FDRMNP $+1 >2B MAX NUMBER OF PROCEDURES 

FDRMNO $+2 >2C MAX NUMBER OF OVERLAYS 

FDRSIZ $ >100 SIZE IN BYTES OF FDR 

FDRMAG 9 >09 MAXIMUM ACCESS GROUPS ALLOWED 

FDRMNR 5 >05 MAXIMUM # OF RIGHTS DEFINED 
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* 


* 


* FILE IDENTIFICATION (FID) 

* 


02/22/80 * 
* 


* LOCATION: FILES * 

*****;fe**********************:fc****:fe************:*t************* 

* THE FID IS USED TO IDENTIFY WITHIN A FILE ITS NAME AND 

* VERSION NUMBER. THIS IS USED FOR SYSTEM FILES SUCH AS 

* S$CLF AND S$SDTQUE. 

* 

** BEGINNING PACKED RECORD FID 



* 





>00 

! 

FIDNAM 

I 

1 

FILE NAME 


+— 


* 




/ 


/ 

/ 



/ 


/ 

/ 



+— 





>08 

t 

FIDVER 

} 

1 

VERSION NUMBER 


+- 


_+ 

+ 


>0A 

! 


j 

1 



+- 


-+ 



>0C 

j 


J 

I 



+— 


-H 

+ 


>0E 

SIZE 


** END 

OF PACKED RECORD 
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* * 


* 

* 

FILE INFORMATION RECORD 

(FIR) 

11/24/82 

* 

* 

* 

LOCATION: DISK 



* 


*********************************************************** 

* THE FIR IS USED BY THE TASKS WHICH ASSIGN, MODIFY, LIST, 

* AND DELETE USER IDS. IT IS A VARIANT OF THE CAPABILITIES 

* LIST FILE RECORD (CLR). FOR DETAILS SEE CLR. 
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FSC 


4ck'k-k-k^ck4(ic'k‘kick4cJfk‘k-ki(ic:k‘k‘k^ick-k-k'k‘kifk‘k'k’k:kit:!fk-k:k’k:ki<icifk^'ki<'kifk-k-k-k-k'ki('f: 


* * 

* FILE STRUCTURE COMMON (FSC) 02/23/82 * 

* * 

* LOCATION: FILE MANAGEMENT TABLE AREA * 

* * 


* THE FSC IS COMPOSED OF A COMMON FIRST STRUCTURE THAT IS 

* SHARED BY BOTH THE FILE CONTROL BLOCK (FCB) AND THE FILE 

* DIRECTORY BLOCK (FDB) VARIANTS OF THE REMAINDER OF THE 

* STRUCTURE. 

* THE FCB IS AN IN-MEMORY REPRESENTATION THAT IS USED TO 

* TRACK THE CHARACTERISTICS OF A FILE THAT IS IN USE. AN FCB 

* REPRESENTS THE LAST COMPONENT OF THE FILE PATHNAME. 

* THE FDB IS AN IN-MEMORY STRUCTURE REPRESENTING ONE NODE 

* OF THE PATHNAME OF A FILE. IT PROVIDES TREE LINKAGE FOR 

* THE ENTIRE FILE PATHNAME. 


* 1 * 

>00 ! FSCPDT ! PDT POINTER 

H — — — — — — — — — — — — — — — — — I- 

>02 ! FSCPDR ! PTR TO PARENT'S DIRECTORY DOOR 

H — — — — — — — — 

>04 ! FSCEOM ! END OF MEDIUM LOGICAL REC # 

+ + + 

>06 ! ! 

+ + + 

>08 ! FSCAPB ! FSCBPA ! ADUS PER BLOCK 

+ + + BLOCKS PER ADU 

>0A ! FSCPAS ! PRIMARY ALLOCATION SIZE 

+ + + 

>0C ! FSCPAA ! PRIMARY ALLOCATION ADDRESS 

+ + + 

>0E ! FSCSAA ! SAT ADDRESS 

H — — _ — — 1- 

>10 ! FSCPRS ! PHYSICAL RECORD SIZE 

H — — — H — h 

>12 ! FSCADU ! FDR ADU OF THIS FILE 

+ 1 - — — — — — — 

>14 ! FSCOFF ! FSCMFG ! FDR OFFSET WITHIN ADU 

+ + + MODIFIED ONLY FLAGS 

FCB - FILE CONTROL BLOCK VARIANT 
* 1 — — — * 

>16 ! FCBFCB ! LINK FOR CONCATENATED FILES 

H — _ — — — — — — — — — — — — + 

>18 ! FCBRPB ! START OF RPB CHAIN 

H — — — -I — . j- 

>1A ! FCBCCT ! FCBFLB ! COUNT OF CONCATENATED FILES 

+ + + FLAGS BYTE 

>1C ! FCBSGB ! SGB ADDRESS 
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>1E 

+- 

1 

FCBSMT 

— + 

f 

>20 

"T*“ 

j 

FCBFLG 

j 

>22 

T — 

J 

FCBFDB 

1 

>24 

T*** 

J 

FCBSFD 

! 

>26 

I 

FCBLRS 

! 

mmJL 

>28 

f 

FCBSAS 

I 

>2A 

T* 

1 

FCBBKM 

1 

>2C 

! 


! 

>2E 

T“* 

! 

FCBOFM 

i 

>30 

“1““ 

! 

FCBLRL 

! 

>32 

f 

FCBEXT 

"“T 

j 

.-J. 

>34 

“r*" 

f 

-L- — 


1 

>36 

I 

FCBXCT ! FCBCLA 

! 

>38 

*T“ 

j 

FCBRLA 

“*T 

I 

>3A 

I 

FCBCPO ! FCBCAW 

1 





>3C 

*- 

1 

FCBEBQ 

1 

>3E 

J 


**T 

f 

>40 

“1“““ 

! 

FCBCLB 

•"T 

1 

>42 

I 

FCBFBQ ! 

j 

>44 

! 

! 

1 

>46 

1 

FCBBTR 

I 

>48 

f 

FCBSBB 

I 

>4A 

J 

FCBMRS 

f 

>4C 

I 

FCBKDB ! 

? 


/ 

/ 

“T" 

/ 


SM TABLE AREA SSB OF SGB 
FILE FLAGS 

POINTER TO DIRECTORY ENTRY 
SSB OF DIRECTORY ENTRY 
LOGICAL RECORD SIZE 
SECONDARY ALLOCATION SIZE 
END OF MEDIUM BLOCK # 

END OF MEDIUM OFFSET 
LOCKED RECORD LIST HEAD 
BLOCK COUNT FOR FILE EXTENT 

FILE EXTENSION COUNT 

COUNT OF THINGS POINTING HERE 
REQUEST LIST ANCHOR 

COUNT OF PASSIVE OPERATIONS 
COUNT OF ACTIVE WAITERS 

EMPTY BLOCK QUEUE 

CURRENT LOG BLOCK # 

FREE BLOCK QUEUE HEAD 

B-TREE ROOTS BLOCK # 

STARTING BUCKET BLOCK # 

MINIMUM KIF RECORD SIZE 
KEY DESCRIPTIONS BLOCK 
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FSC 


/ / / 

+ + + 


* 1 * 


>3C 

j 

FCBMNT ! FCBTO 

1 


+- 

+ 

--+ 

>3E 

j 

FCBTR 

1 


+— 

+ 

-- + 

>40 

! 

FCBMNP ! FCBPO 

1 


+- 

+ 

--+ 

>42 

1 

FCBPR 

1 


+- 

+ 


>44 

! 

FCBMNO ! FCBOO 

t 


+ * 

+ 


>46 

1 

FCBOR 

I 


+- 

+ 

--+ 




FDB 


* _ 



>16 

! 

FDBRNM 

j 


+- 

+ 

--+ 

>18 

I 

FDBDDR 

j 


+- 


--+ 

>1A 

1 

FDBFNM ! 

j 


+- 


— + 


MAXIMUM NUMBER OF TASKS 

TASK DIRECTORY ENTRY OFFSET 
TASK DIRECTORY ENTRY RECORD # 

MAXIMUM NUMBER OF PROCEDURES 
PROC DIRECTORY ENTRY OFFSET 
PROC DIRECTORY ENTRY RECORD # 

MAXIMUM NUMBER OF OVERLAYS 

OVERLAY DIRECTORY ENTRY OFFSET 
OVERLAY DIRECTORY ENTRY RECORD 


- FILE DIRECTORY BLOCK VARIANT 
RECORD NUMBER OF FDR 
ADDRESS OF DIRECTORY DOOR (DDR) 
FILE NAME 


/ / / 

/ / / 


>22 

+- 

I 

+ 

FDBFCB 

-+ 

! 

ADDRESS OF FCB ANCHOR 


>24 

! 

FDBCDF ! FILL02 

! 

COUNT OF DESCENDANTS 
RESERVED 

ADDRESS OF FIRST DESCEN 


>26 

I 

FDBAFD 

f 

DANT (AFD) 

>28 

! 

FDBSAF 

j 

SSB ADDRESS FOR AFD 


>2A 

“r*“ 

1 

FDBALS 

j 

ADDRESS OF LAST SIBLING 

(ALS) 

>2C 

t 

FDBSAL 

j 

SSB ADDRESS FOR ALS 


>2E 

1 

FDBANS 

f 

ADDRESS OF NEXT SIBLING 

(ANS) 

>30 

*1“ 

J 

FDBSAN 

J 

SSB ADDRESS FOR ANS 


>32 

! 

FDBAPF 

J 

.. 4 . 

ADDRESS OF PARENT FILE 

(APF) 

>34 

I 

FDBSAP 

f 

««. 4 - 

SSB ADDRESS FOR APF 


>36 

I 

+- 

FDBFMT 

j 

-+ 

SSB ADDRESS FOR THIS FDB 
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FLAGS FOR FIELD: FSCMFG #15 - MODIFIED ONLY FLAGS 

FSCMEC = (X ) - 1 = END OF MEDIUM HAS CHANGED 

FSCMWT = (.X ) “ 1 = FILE HAS BEEN WRITTEN IN 

FSCFUl = (..XX ) - FILE USAGE BIT ONE 

FSCDEL = (....X ) - FDB DELETE PROTECTION FLAG 

* 

* 


FLAGS FOR FIELD: FCBFLB #1B - FLAGS BYTE 

FCBFCC = (X ) - FILE IS IN CONCATENATION 

FCBFUB = (.X ) - OPEN MUST BE UNBLOCKED 

FCBBSY = (..X ) - FCB IS BUSY 

FCBFSE = (...X ) - SUPPRESS EOF BEFORE EOM 

FLAGS FOR FIELD: FCBFLG #20 - FILE FLAGS 

FCBFFU = (XX ) - FILE USAGE FLAGS 

* 00 = NO SPECIAL USAGE 

* 01 = DIRECTORY 

* 10 = PROGRAM 

* 11 = IMAGE 

FCBFDF = (..XX ) - DATA FORMAT 

* 00 = NON-BLANK SUPPRESSED 

* 01 = BLANK suppressed 

* 10 & 11 = RESERVED 

FCBFAT = (....X ) - EXPANDABLE IF ON 

FCBFFT = ( XX ) - FILE TYPE 

* 00 = RESERVED (FOR DEVICE) 

* 01 = SEQUENTIAL 

* 10 = RELATIVE RECORD 

* 11 = KEY INDEXED 

FCBFWP = ( X ) - WRITE PROTECTED IF ON 

FCBFDP = ( X ) - DELETE PROTECTED IF ON 

FCBFTF = ( X ) “ temporary FILE IF ON 

FCBFBF = ( X ) - BLOCKED FILE IF OFF 

FCBFAF = ( X....) - ALIAS ENTRY IF ON 

FCBFFW = ( X...) - FORCED WRITE IF ON 

FCBFSC = ( X..) - FILE SECURITY 

FCBPLG = ( X.) - FILE MARKED AS PARTIAL LOGGING 

RESER = ( X) - RESERVED 


EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


FSCFU2 FSCFUl+1 >03 FILE USAGE BIT TWO 

FSCFUM >3000 >3000 FILE USAGE MASK 

FSCSIZ $ >16 FSC SIZE 
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FSC 


FCBFFM >C000 >C000 FILE USAGE FLAGS MASK 

FCBFAM >3000 >3000 FILE FORMAT FLAGS MASK 


FCBFTM 

>0600 

>600 

FCBMSZ 

$ 

>3C 

FCBSIZ 

$ 

>86 

FCBPSZ 

$ 

>48 

FCBPDT 

FSCPDT 

>00 

FCBPDR 

FSCPDR 

>02 

FCBEOM 

FSCEOM 

>04 

FCBAPB 

FSCAPB 

>08 

FCBBPA 

FSCBPA 

>09 

FCBPAS 

FSCPAS 

>0A 

FCBPAA 

FSCPAA 

>0C 

FCBSAA 

FSCSAA 

>0E 

FCBPRS 

FSCPRS 

>10 

FCBADU 

FSCADU 

>12 

FCBOFF 

FSCOFF 

>14 

FCBMFG 

FSCMFG 

>15 

FCBMEC 

FSCMEC 

>00 

FCBMWT 

FSCMWT 

>01 

FDBMSZ 

$ 

>38 

FDBPDT 

FSCPDT 

>00 

FDBPDR 

FSCPDR 

>02 

FDBEOM 

FSCEOM 

>04 

FDBAPB 

FSCAPB 

>08 

FDBBPA 

FSCBPA 

>09 

FDBPAS 

FSCPAS 

>0A 

FDBPAA 

FSCPAA 

>0C 

FDBSAA 

FSCSAA 

>0E 

FDBPRS 

FSCPRS 

>10 

FDBADU 

FSCADU 

>12 

FDBOFF 

FSCOFF 

>14 

FDBMFG 

FSCMFG 

>15 

FDBMEC 

FSCMEC 

>00 

FDBMWT 

FSCMWT 

>01 

FDBFUl 

FSCFUl 

>02 

FDBFU2 

FSCFU2 

>03 

FDBFDL 

FSCDEL 

>04 


FILE TYPE FLAGS MASK 
MIN FCB SIZE 
MAX FCB SIZE 
PROGRAM FILE FCB SIZE 
PDT ADDRESS 

PTR TO PARENT'S DIRECTORY DOOR 

END OF MEDIUM LOGICAL REG. # 

ADUS PER BLOCK 

BLOCKS PER ADU 

PRIMARY ALLOCATION SIZE 

PRIMARY ALLOCATION ADDRESS 

SAT ADDRESS 

PHYSICAL RECORD SIZE 

FDR ADU FOR THIS FILE 

FDR OFFSET WITHIN ADU 

MODIFIED ONLY FLAGS 

1= EOM HAS CHANGED 

1= FILE WAS WRITTEN IN 

FDB SIZE 

PDT ADDRESS 

PTR TO PARENT'S DIRECTORY DOOR 

END OF MEDIUM LOGICAL REC. # 

ADUS PER BLOCK 

BLOCKS PER ADU 

PRIMARY ALLOCATION SIZE 

PRIMARY ALLOCATION ADDRESS 

SAT ADDRESS 

PHYSICAL RECORD SIZE 

FDR ADU FOR THIS FILE 

FDR SECTOR OFFSET IN ADU 

MODIFIED ONLY FLAGS 

1 = EOM HAS CHANGED 

1 = FILE WAS WRITTEN IN 

FILE USAGE BIT ONE 

FILE USAGE BIT TWO 

FDB DELETE PROTECTION FLAG 
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*****************************************************:%****** 
* * 

* FILE MANAGER WORK AREA (FWA) 01/21/82 * 

* * 

* LOCATION: SYSTEM AREA * 

************************************************************ 

* THE FWA IS USED BY FILE MANAGEMENT AND BY KI F MANAGEMENT 


AS 

A 

GENERAL WORK AREA. 

R 
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— 4. 
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I 

m4- 

>32 

"T* 
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FWALFG 

! 

— 4- 

>34 

“r* 

I 

FWAFFC 

f 

— 4. 

>36 

*T" 

FWAFMT 

f 

>38 

“r“ 

f 

FWAFCB 

I 

>3A 

"t** 

FWABST 

f 

>3C 

■r* 

FWABSB 

f 

«»4- 

>3E 


FWAPRS 

f 

^4. 

>40 

T"“ 

FWAUBT 

J 

.4. 

>42 

I 

+- 

FWAUBS 

! 

-+ 


WORKSPACE USED BY FM 


MIDDLE SEGMENT FLAGS 
MULTIRECORD CHARS TRANSFERRED 
CURRENT OVERLAY AREA ADDRESS 
SAVED PROGRAM COUNTER 
BLWP VECTOR FOR RETURNING 

SAVED RPBBN (2 WORDS) 

SAVED RPBOCB 

SAVED LDT FLAGS 

FIRST FCB FOR CC FILES 

SSB FOR THE FMT WITH THE FCB 

FCB ADDRESS IN THE FMT 

SMT SSB ADDR FOR BUFFER 

SSB ADDR FOR BUFFER 

PHYSICAL RECORD SIZE 

USER BUFFER SMT SSB ADDR 

USER BUFFER SSB ADDRESS 
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FWA 


>44 ! 

+ 

FWAUBO 

+ 

1 

— — — + 

USER BUFFER OFFSET 


>46 ! 

+ 

FWAUBL 

1 

— — — + 

USER BUFFER LENGTH 


>48 ! 

+ 

FWAFMB 

+ 

f 

+ 

FMT BIAS 


>4A ! 

+ 

FWARNl 

+ 


REGORD # RELATIVE TO 

CURRENT 

>4C ! 

FWARN2 

j 

FILE OF concatenated 

SET 

>4E ! 

+ 

FWAOOB 

+ 

1 

OLD OFFSET IN USER BUFFER 

>50 ! 

+ 

FWAUBR 

+ 

! 

+ 

BUFFER LENGTH REMAINING 

>52 ! 

+ 

FWAFFG 

+ 

f 

— — — + 

FILE MGR FLAGS 


>54 ! FWASTK ! 

+ + 

/ / 

/ / 

+ + 

! 

+ 

/ 

/ 

+ 

STACK AREA 


FLAGS FOR 

FIELD: FWAFFG 

#52 

- FILE MGR FLAGS 


FWAPOP = 

(X 

) 

- PASSIVE OPERATION 

FLAG 

FWAQW = 

( .X 


- QUEUED TO WAITING 

QUEUE IN 

EQUATES : 

LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


FWASIZ 

$ 

>F4 

SIZE OF FWA INCLUDING WSP 
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* * 

* I/O REQUEST BLOCK (IRB) 09/09/83* 

* * 

* LOCATION: SYSTEM TABLE AREA AND JCA * 

* * 


************************************************************ 

* THE IRB TEMPLATE HAS FOUR MAJOR VARIANTS. ONE OF THESE IS 

* THE SIMPLE CALL BLOCK FOR RESOURCE INDEPENDENT I/O. ONE 

* HAS EXTENSIONS FOR VDT DEVICES. ANOTHER IS THE CALL 

* BLOCK USED FOR I/O UTILITY CALLS. IT INCLUDES INTERNAL 

* VARIANTS FOR REMOTE I/O HANDLING AND FOR LOGICAL NAME 

* SEGMENT HANDLING. THERE IS ALSO A SET OF EQUATES USED BY 

* THE CODE WHICH CREATES PROGRAM FILES. EQUATES FOR SPECIAL 

* PURPOSES IN CREATING KEY INDEXED FILES AND FOR REFERENCE 

* TO SPECIAL APPLICATIONS OF THE BASIC I/O BLOCK ARE IMBEDDED 

* IN THE TEMPLATE WHERE THE ORIGINAL FIELDS ARE DEFINED. 

* A FINAL VARIANT IS USED FOR FILE I/O CALL BLOCKS. 

* 

* NOTE THAT FOR DUPLICATE LABELS, THE PREFERRED USAGE IS 

* STARRED IN THE COMMENT COLUMNS. 

** beginning packed record IRB 


* 1 * 

>00 ! IRBSOC ! IRBEC ! SUPERVISOR REQUEST CODE 

+ + + ^REQUEST ERROR CODE 

>02 ! IRBOC ! IRBLUN ! *SUB-OPERATION CODE 

+ + + LOGICAL UNIT 

>04 ! IRBSFL ! IRBUFL ! ^SYSTEM FLAGS 

+ + + REQUESTOR (USER) FLAGS 

resource-independent I/O VARIANT 

>06 ! IRBDBA ! *DATA BUFFER ADDRESS 

H 1 J- 

>08 ! IRBICC ! . *INPUT CHAR COUNT / ACTUAL OUTPUT 

_l 1- 

>0A ! IRBOCC ! *OUTPUT CHAR COUNT / ACTUAL INPUT 

+ + + 

FILE I/O VARIANTS 
* + * 

>0C ! IRBCBA ! CURRENCY BLOCK ADDRESS 

+ + + 

* 1 * 

>0C ! IRBRNl ! RELATIVE RECORD NUMBER 

+ + + 

>0E ! ! 

+ -f + 
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IRB 


>10 ! FILLOl ! 

+ + + 

DIAGNOSTIC PORT VARIANT 

— — — 

>0C ! IRBVRS ! IRBOLF ! OS VERSION/RELEASE 

+ + + ONLINE FLAGS 

>0E ! IRBPCD ! DYNAMIC PASSCODE 

DIRECT DISK I/O 

>0C ! IRBADU ! ADD ADDRESS 

+ — — — (- 

>0E ! IRBOFF ! SECTOR OFFSET 

+ + + 

i( 1 

>0C ! IRBTRK ! TRACK ADDRESS 

-) — — I- — — *- h 

>0E ! IRBSPR ! IRBSCT ! SECTORS PER RECORD 

+ + + SECTOR 

SUBOPCODE >18 VARIANT 

* — _ — — — — — ..f... — — — — * 

>0C ! IRBDKS ! TPCS (RO) DISK STATUS FOR >18 

H — —H — — — — —-f- 

>0E ! IRBCRS ! TPCS (R7) CONTROLLER STAT FOR >18 

H 1 -— — 1 .- 1 - 

TERMINAL DEVICE I/O VARIANTS 

* + * 

>0C ! IRBRPY ! REPLY BLOCK ADDRESS 

+ + + 

>0E ! IRBXFL ! EXTENDED REQUEST FLAGS 

+ + + 

>10 ! IRBFCH ! IRBEVT ! VDT FILL CHARACTER 

+ + + VDT EVENT BYTE 

>12 ! IRBCRO ! IRBCCO ! VDT CURSOR IN FIELD ROW 

+ + + VDT CURSOR IN FIELD COLUMN 

>14 ! IRBFRO ! IRBFCO ! VDT FIELD BEGINNING ROW 

+ + + VDT FIELD BEGINNING COLUMN 

* H * 

>0C ! IRBVTA ! VALIDATION TABLE ADDRESS 

+ + + 

I/O UTILITY VARIANT 

* 1 * 

>06 ! IRBTYP ! IRBTFL ! RESOURCE TYPE 

+ + + RESOURCE TYPE FLAGS 
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>08 

f 

IRB JSB 

j 

mM 

OWNER JSB ADDRESS (lOU SVC >A5) 

>0A 

-r 

I 

IRBTSB 

1 

-4- 

OWNER TSB ADDRESS ( lOU SVC >A5) 

>0C 

i 

IRBKDB 

1 

• 4- 

KEY DESCRIPTOR ADDRE S S /OVERLAYS IRBA 

>0E 

j 

FILL04 

f 

-4. 

OVERLAYS IRBOFF 

>10 

+ — — — 

! 

IRBFLG 

! 

>4- 

UTILITY FLAGS (2 BYTES) 

>12 

*r — 

I 

IRBDLL 

! 

-4- 

DEFINED LOGICAL RECORD LENGTH 

>14 

«JU . 

f 

IRBDPL 

! 

m,JL 

DEFINED PHYSICAL RECORD LENGTH 

>16 

~r * 

j 

IRBPNA 

\ 

-4- 

PATHNAME ADDRESS 

>18 

"T — — — 

f 

IRBPRM 

j 

1.4- 

PARAMETER POINTER 

>1A 

-r 

! 

IRBRES 

! 

1.4- 

RESERVED 

>1C 

-r 4-* — — . 

! 

I RBI FA 

I 

initial file allocation (2 WORDS) 

>1E 

“T 

1 


j 

»4. 


>20 

"T — ■ * 

f 

IRBSFA 

I 

-4- 

secondary file allocation (2 WORDS) 

>22 

“T — » — 

! 


I 

-4- 



“T » 





4 

-1_ 

lOU 

- it 

VARIANT FOR LOGICAL NAME SEGMENT 

>24 

! IRBSTG ! IRBNMF 

1 

-•4- 

TASK STAGE NUMBER 

NAME MANAGER FLAGS 

REDIRECTED RESOLVED PATHNAME 

EQUATES FOR CREATE PROGRAM FILE V 
OF PACKED RECORD 

>26 

! 

-J- 

IRBRPN 

1 

i-4- 

>28 

SIZE 

** 

END 


FLAGS FOR FIELD: IRBSFL //04 

IRFBSY = (X ) - 

IRFERR = ( .X ) - 

IRFEOF = ( . . X ) - 

IRFVNT = (...X ) - 

= ( . . . . XXX ) - 

IRFMDT = ( X ) - 

FLAGS FOR FIELD; IRBUFL #05 

IRFINT = (X ) - 

IRFRPY = (.X ) - 


^SYSTEM FLAGS 

BUSY 

ERROR 

END OF FILE 
EVENT CHAR 

MODIFIED DATA TAG (OPCODE >17) 


REQUESTOR (USER) FLAGS 

INITIATE REQUEST 
OUTPUT WITH REPLY 
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IRB 


IRFSAR = (..X ) - SECURITY ACCESS RIGHTS (OPCODE >5) 

IRFACC = (...XX ) “ ACCESS PRIVILEGES 

* 00=EXCLUSIVE WRITE 

* 01=EXCLUSIVE ALL 

* 10=SHARED 

* 11=READ ONLY 

IRFLOC = ( X ) - *LOCK/UNLOCK 

IRFOWN = ( XX ) - OWNERSHIP LEVEL 

FLAGS FOR FIELD: IRBOLF #0D - ONLINE FLAGS 

OLDBFR = (X ) - BUFFER ADDRESS SPECIFIED 

* 0=NO BUFFER IN TIL. IMAGE 

* 1=BUFFER IN TILINE IMAGE 

= (.XXXXXXX ) - RESERVED (SET TO 0) 

FLAGS FOR FIELD: IRBXFL //OE - EXTENDED REQUEST FLAGS 

IRFCSF = (X ) - CURSOR START OF FIELD DEFN 

IRFNTN = (.X ) - intensity 

IRFFKR = (..X ) - BLINKING CURSOR (FLICKER) 

IRFGRA = (...X ) - GRAPHICS DISPLAY(CHAR LT >20) 

IRFEBA = (....X ) - 8-BIT ASCII 

IRFTER = ( X ) - ENABLE TASK EDIT CHAR RETURN 

IRFBP = ( X ) - BEEP 

IRFRDB = ( X ) - RIGHT DISPLAY EDGE BOUNDARY 

IRFCIF = ( X .) - CURSOR IN-FIELD DEFINED 

IRFFC = ( X ) - FILL CHAR DEFINED 

IRFIF = ( X ) - INITIALIZE FIELD 

IRFRFF = ( X....) - REMAIN IN FULL FIELD 

IRFECO = ( X. . . ) - ECHO 

IRFVRQ = ( X..) - VALIDATION REQUIRED 

IRFVER = ( X.) - VERIFICATION ERROR 

IRFWBP = ( X) - WARNING BEEP 

FLAGS FOR FIELD: IRBTFL #07 - RESOURCE TYPE FLAGS 

= (XXX ) - RESERVED 

IRFVD = (...X ) - VIRTUAL DEVICE 

IRFREM « (....X ) - REMOTE CHANNEL 

IRFCHN = (.....X ) - CHANNEL 

IRFDEV = ( X ) - DEVICE 

IRFFIL = ( X ) - FILE 

FLAGS FOR FIELD: IRBFLG #10 - UTILITY FLAGS (2 BYTES) 

IRFFCA = (X ) - FILE CREATED BY ASSIGN 

IRFFUl = (.XX ) - FILE USAGE FLAGS 

* 00=NO SPECIAL USAGE 

2270512-9701 22—75 Structure Pictures 



IRB 


DNOS System Design Document 


01=DIRECT0RY FILE 
10=PR0GRAM FILE 
11=IMAGE FILE 

IRFSCl = (...XX ) - LUNO SCOPE 


* 00=TASK LOCAL 

* 01=J0B LOCAL 

* 10=GLOBAL 

* 11=SHARED 

IRFGEN = ( X ) - AUTOGENERATE LUNO 

IRFACR = ( X ) - REQUEST AUTOCREATE FILE 

IRFPRM = ( X ) “ 1=IRBPRM VALID (FARMS PRESENT) 

IRFLRL = ( X ) - 1 = VALID LOGICAL RECORD LENGTH 

IRFTMP = ( X ) - FILE IS TO BE TEMPORARY 

IRFIMW = ( X ) - IMMEDIATE WRITE DISK FILES 

IRFDFl = ( XX...) - DATA FORMAT 

* 00=NORMAL RECORD IMAGE 

* 01=BLANK SUPPRESSED 

* 10,11 RESERVED 

IRFALL = ( X..) - ALLOCATION MAY GROW 

IRFFTl = ( XX) - FILE TYPE 

* 00=RESERVED 

* 01=SEQUENTIAL FILE 

* 10=RELATIVE RECORD FILE 

* 11=KEY INDEXED FILE 

FLAGS FOR FIELD: IRBNMF #25 -NAME MANAGER FLAGS 

IRFRID = (X ) - USE SPECIFIED RUN ID 

IRFNMl = (.XXXXXXX ) - RESERVED AT PRESENT 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

IRBERR 

IRBEC 

>01 

IRBOP 

IRBOC 

>02 

IRBSFG 

IRBSFL 

>04 

IRFVAL 

IRFRPY 

>01 

IRFKFG 

IRFRPY 

>01 

IRFBFI 

IRFRPY 

>01 

IRFRES 

IRFSAR 

>02 

IRFACl 

IRFACC+1 

>04 

irfrln 

IRFACC 

>03 

IRFACM 

>0018 

>18 

IRFOS 

IRFACC 

>03 

IRFOSF 

IRFACC+1 

>04 

IRFMDS 

IRFLOC 

>05 

IRFLFG 

IRFLOC 

>05 

IRFTIH 

IRFLOC 

>05 

IRFIMO 

IRFLOC 

>05 

IRFPAS 

IRFLOC 

>05 


DESCRIPTION 


REQUEST ERROR CODE 

SUB-OPERATION CODE 

SYSTEM FLAGS 

READ WITH VALIDATION 

KEY SPECIFIES FLAG 

BUFF HAS WRITE INTERLEAVED FMT 

ACCESS PRIVILEGES 

MASTER RESOLVE LOGICAL NAMES 

ACCESS PRIV. BIT MASK 

READ BY TRACK/OFFSET ENABLED 

READ BY TRACK/OFFSET FORWARD 

MASTER DO NOT SUSPEND 

LOCK/UNLOCK 

READ BY track/transfer INHIBIT 
IMMEDIATE OPEN FLAG FOR TP D 
PASS THRU MODE FOR COMM DSRS 
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IRB 


IRFEXR 

IRFOWN 

>06 

IRFBAD 

IRFOWN+1 

>07 

IRFBFG 

IRFBAD 

>07 

IRFWPM 

IRFOWN+1 

>07 

IRFRTY 

IRFOWN+1 

>07 

VARNTl 

$ 

>06 

IRBRLN 

IRBICC 

>08 

IRBLRL 

IRBICC 

>08 

IRBCHT 

IRBOCC 

>0A 

IRBCMD 

IRBOCC 

>0A 

IRBHD 

IRBOCC+l 

>0B 

VARNT2 

$ 

>0C 

IRBCYL 

IRBRNl 

>0C 

IRBRN2 

IRBRNl+2 

>0E 

IRBFWA 

$ 

>10 

IRBRT 

IRBXFL 

>0E 

IRBLRN 

IRBKDB 

>0C 

IRBPRS 

IRBKDB 

>0C 

IRFFU2 

IRFFUl+1 

>02 

IRFFUM 

>6000 

>600 0 

IRFSC2 

IRFSCl+1 

>04 

IRFSCM 

>1800 

>1800 

IRFDF2 

IRFDFl+1 

>0C 

IRFDFM 

>0018 

>18 

IRFFT2 

IRFFTl+1 

>0F 

IRFFTM 

>0003 

>03 

IRBIF2 

IRBlFA+2 

>1E 

IRBRCS 

$ 

>24 

VARNT3 

$ 

>24 

IRBMXT 

IRBRPY+1 

>0D 

IRBMXP 

IRBXFL 

>0E 

IRBMXO 

IRBXFL+1 

>0F 


EXTENDED REQUEST 

*BLANK ADJ/SET EVENT MODE 

BLANK ADJ/SET EVENT MODE 

WORD PROCESSING MODE 

READ BY TRACK WITH NO RETRIES 

RECORD LENGTH 

logical record length 

OUTPUT character COUNT 
COMMAND FOR SUBOPCODE >18 
HEAD # FOR SUBOPCODE >18 

cylinder ADDRESS FOR SUBOP >18 
SECOND WORD OF RECORD NUMBER 
POINTER TO FILE WORK AREA 
RESOURCE TYPE/TYPE FLAGS FOR CC 
LOGICAL RECORD NUMBER 
PHYSICAL RECORD SIZE (DIR OVHD.) 
FILE USAGE FLAGS 

FILE USAGE BIT MASK 
LUNO SCOPE 

LUNO SCOPE BIT MASK 
DATA FORMAT 
DATA FORMAT BIT MASK 
FILE TYPE 

FILE TYPE BIT MASK 

INITIAL FILE ALLOCATION (2ND WORD 
REQUESTOR CALL BLOCK SIZE 

MAXIMUM NUMBER TASKS IN PROG FILE 
MAX NUMBER PROGS IN PROG FILE 
MAX NUMBER OVERLAYS IN PROG FILE 
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************************************************************ 


* * 

* JOB INFORMATION TABLE (JIT) 01/23/80 * 

* * 

* LOCATION: JCA * 


************************************************************ 

* THE JIT DESCRIBES THE JOB COMMUNICATION AREA (JCA) CONTENTS 

* AND IS FOUND AT THE ADDRESS JCASTR (FOUND IN NFPTR) IN 

* EACH JOB. IT INCLUDES DESCRIPTIVE INFORMATION ABOUT THE 

* JOB AND POINTERS TO MANY JOB-LOCAL STRUCTURES IN THE JCA. 

* (NOTE THAT JITOVB MUST BE ON A BEET BOUNDARY.) 


* 1 ._* 


>00 

1 

JITHED 

1 


+- 


-+ 

>02 

1 

JITLNK 

j 


+- 

+ 

-+ 

>04 

! 

JITRES 

1 


+ - 


-+ 

>06 

I 

JITEND 

1 


+ - 

+ 

-+ 

>08 

! 

JITUSE 

j 


+— 


-+ 

>0A 

! 

JITHI 

1 


+- 

+ 

-+ 

>0C 

! 

JITPTR 

j 


+- 

+ 

- + 

>0E 

1 

JITCAP 

f 


+- 


— + 

>10 

1 

JITSEM 

! 


+- 

+ 

-+ 

>12 

I 

JITLDT 

! 


+- 

+ 

-+ 

>14 

I 

JITIOC ! JITLUN 

J 


+- 


-+ 

>16 

i 

JITTYP ! JITTF 

1 


+— 

+ 

-+ 

>18 

} 

JITFLG 

} 


+- 

+ 

-+ 

>1A 

I 

JITRLK 

1 


+- 


-+ 

>1C 

! 

JITOTS 

1 


+- 

+ 

-+ 

>1E 

j 

JITJSB 

1 


+- 

+ 

-+ 

>20 

I 

JITPRM 

1 


+- 


-+ 

>22 

! 

JITROB 

f 


+- 

+ 

— + 

>24 

I 

JITCCB 

1 


+- 

+ 

-+ 


SYSTEM TABLE AREA OVERHEAD 

STA - LINK TO FIRST BLOCK 

STA - RESERVE LIMIT 

STA - end of AREA 

STA - TOTAL BYTES USED 

STA - highest ADDR USED 

POINTER TO JSB OF JCA OWNER 

POINTER TO capability LIST 

POINTER TO SEMAPHORE LIST 

JOB LOCAL LDT - LDT LINK 

LDT - INITIATE I/O COUNT 
LDT - LUNO 
LDT - RESOURCE TYPE 

LDT - RESOURCE FLAGS 
LDT - LDT FLAGS 

LDT - RESOURCE LINK 

LDT - OWNER TSB 

LDT - OWNER JSB 

LDT - parameter LIST 

POINTER TO RESOURCE OWNER BLK 

POINTER TO CHANNEL CONTROL BLK 
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JIT 


>26 

I 

JITPAS 

j 

j 

.4-. 


/ 

/ 


/ 

/ 

/ 

/ 

>2E 

I 

JITACC 

mu-J- . . « » _ iiu . .. 

1 

_1_ 

I 


“r“" 

/ 

/ 


/ 

/ 

i_ 

/ 

/ 

>3E 

“T* 

I 

JITPVL 

! JITLID 

f 

— 4- 

>40 

"r*“ 

J 

-1.. 

JITTID 

1 wa x.- ILJ 

j 

f 

.4- 


/ 

/ 


/ 

/ 

/ 

/ 

..4- 

>60 

"r“" 

I 

JITJBI 

f 

>62 

I 

JITFTB 

! 

>64 

f 

JITFLK 

f 

>66 

T*" 

! 

JITBLK 

! 

mmM 

>68 

“T* 

f 

JITFTP 

f 

«»4. 

>6A 

I 

JITFJB 

-L. 

1 

>6C 

f 

FILLOO 

! 

_L 

““T 

J 

«4- 


/ 

/ 


/ 

/ 

JL 

/ 

/ 

>80 

"T — 

I 

JITFMQ 

1 

JL 

"•“T 

j 


“r* 

/ 

/ 


f 

1 

/ 

/ 

>8C 

I 

JITEXC 

} 

>8E 

I 



j 

>90 

! 

FILLOl 

j 

>92 

“T* 

J 

JITWOT 

"•T” 

1 

>94 

J 

FILL02 

“•"T 

f 

— 4- 

>96 

■T“" 

I 

JITSSI 

f 

..4- 

>98 

“T 

f 

4 - — 

JITSSS 

f 

— j- 


PASSWORD FOR USER ID 

ACCOUNT ID 

USER PRIVILEGE LEVEL 
LAST TASK ID GIVEN 
TSB RUN TIME ID BIT MAPS 

SEGMENT ID OF JCA 
POINTER TO FM TSB 
FORWARD TOL LINK FOR FM 
BACKWARD TOL LINK FOR FM 
FM TASK TYPE (>0100) 

POINTER TO FM JSB 
FILLER FOR DUMY OV B 

FM QUEUE FOR JOB 

EXECUTION TIME SINCE LOAD 

CURRENTLY UNUSED 
TABLE AREA WAIT QUEUE 
RESERVED AT PRESENT 
SYNONYM SEGMENT RUN ID 
SYNONYM SEGMGR TAB AREA SSB 
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>9A 

f 

JITSSB 

j 

>9C 

"T — 

t 

JITRST 

j 

>9E 

"1““ 

! 

JITTSB 

f 

>A0 

T*" 

I 

JITACT 

1 

>A2 

! 

JITWOM 

-I- 

! 

>A4 

i 

JITFMW 

J 

! 


^mm 

/ 

/ 


/ 

/ 

1 

/ 

/ 

>E2 

“T — 

1 

JITINS 

f 

_L 

1 


/ 

/ 


/ 

/ 

/ 

/ 

>EE 

"T “ 

1 

JITDEL 

1 

f 


T""" 

/ 

/ 


/ 

/ 

/ 

/ 

>FA 

“7"“ 

J 

JITASP 

J 

1 


"T* 

/ 

/ 


/ 

/ 

/ 

/ 

106 

I 

JITMAP 

I 

_L 

j 


“T" 

/ 

/ 


/ 

/ 

l_ 

/ 

/ 

1 1 2 

"r“ 

j 

JITINV 

1 

j 


/ 

/ 


1 

1 

-L 

/ 

/ 

1 1 E 

f 

JITRCP 

j 

-1_ 

t 


/ 

/ 

+- 


/ 

/ 

-+ 

/ 

/ 


SYNONYM SSB ADDRESS 

PTR TO RESERVE SEGMENT TABLE 

POINTER TO TSB TREE 

POINTER TO ACTIVE TSBS 

POINTER TO WOM TSBS 

FILE MGR WORKING WP & STACK 

INSTALL TASK QUEUE HEADER 

DELETE TASK QUEUE HEADER 

ASSIGN SPACE QUEUE HEADER 

MAP NAME TO ID QUEUE HEADER 

INITIALIZE NEW VOLUME QUEUE 

RETURN CODE PROCESSOR QUEUE 


EQUATES : 



LABEL 

EQUATE TO 

VALUE DESCRIPTION 

JITOVB 

$ 

>60 

JITSIZ 

$ 

>12A 
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* * 

* JOB MANAGEMENT REQUEST (JMR) 04/28/79 * 

* LOCATION: SYSTEM TABLE AREA * 

* * 
*********************************************************** 

* THE JMR IS A DESCRIPTION OF A JOB MANAGEMENT SVC BLOCK. 

* IT IS USED WITHIN JOB MANAGMENT TO SCAN THE USER'S SVC 

* REQUEST. 


* -I- * 

>00 ! JMRSVC ! JMRERR ! 

+ + + 

>02 ! JMROP ! JMRPRI ! 

4- + + 

>04 ! JMRFLG ! 

H — — — — — — 

>06 ! JMRJID ! 

+ + + 

>08 ! JMRNAM ! ! 

/ / / 

/ / / 

H — — — + — — 4. 

>10 ! JMRTID ! JMRSSZ ! 

H — — — — ~ — — 4- — — — — — — — — — — 4- 
>12 ! JMRPRM ! ! 

>14 ! ! ! 

4 . 4- 4 . 

>16 ! JMRSID ! JMRPFL ! 

4 . 4 . 4 . 

>18 ! JMRSYN ! 

4 . 4- 4 . 

>1A ! JMRLNM ! 

4 1 — }- 

>1C ! JMRUID ! ! 

4 . 4- 4- 

/ / / 

/ / / 

>24 ! JMRPWD ! I 

4 . — 4- 4- 

/ / / 

/ / / 

4 1 — j- 

>2C ! JMRACC ! ! 

4 . 4 4 - 

/ / / 

/ / / 

H 1 + 

2270512-9701 22 


SVC CODE (48) 

ERROR CODE 

JOB MANAGER SUBOPCODE 
JOB priority 

JOB MANAGER CONTROL FLAGS 
JOB ID 

USER SPECIFIED JOB NAME 


TASK ID OF INITIAL TASK 
SIZE OF JCA 1,2,3 
TASK BID parameters 


STATION ID OF TASK (JOB) 

PROGRAM FILE LUNO OF TASK 
SYNONYM SEGMENT SEGMENT ID 

LOGICAL NAME BLOCK SEGMENT ID 

USER ID 


PASSWORD 


ACCOUNT NUMBER 
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FLAGS FOR FIELD: JMRFLG #04 - JOB MANAGER CONTROL FLAGS 


JMFNID = (X ) 

JMFVER = ( .X ) 

JMFBCH = ( . .X ) 

JMFRES = (...XXXXXXXX ) 

JMFPVL = ( XXXXX) 


NEW USED ID SPECIFIED (CREATE) 
BYPASS VERFY CHECKS IN JM 
BATCH JOB 

FLAG BITS 3-10 RESERVED 
PRIVILEGE LEVEL 


EQUATES : 


LABEL EQUATE TO VALUE DESCRIPTION 


JMRSIZ $ 
JMRSZ2 $ 


>10 

>3C 


SIZE OF BASIC CALL 
JMR SIZ FOR CREATE 


BLOCK 

OPERATION 
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JSB 


* 

* JOB STATUS BLOCK (JSB) 09/09/83 

* 


* * * * * 


* 

■k 

* 

* 


* LOCATION: SYSTEM AREA * 

************************************************************ 

* THE JSB PROVIDES THE INFORMATION ABOUT A JOB WHICH IS 

* NEEDED BY DNOS WHETHER OR NOT THE JOB COMMUNICATION AREA 

* IS IN MEMORY. THIS INFORMATION INCLUDES FLAGS, QUEUE 

* LINKS, STATUS INFORMATION, AND JCA LOCATION DATA. 


* — . — — __* 


>00 

i 

JSBJSB 

t 

POINTER TO NEXT JSB 


+- 

+ 

— + 


>02 

i 

JSBJID 

j 

JOB ID (UNIQUE TO SITE) 


+- 


— + 


>04 

I 

JSBFLG ! JSBTCT 

1 

JOB FLAGS 


+- 


-+ 

JOB TASK COUNT 

>06 

1 

JSBPRI ! JSBSTA 

1 

JOB PRIORITY 


+- 


— + 

JOB STATE 

>08 

! 

JSBAPR ! JSBWPR 

1 

ACTIVE PRIORITY (HIGHEST) 


+- 


-+ 

WAITING ON MEMORY PRI(HIGHEST 

>0A 

! 

JSBQL 

f 

ACTIVE QUEUE LINK 


+- 

+ 

-+ 


>0C 

1 

JSBWOM 

f 

LINK FOR WAITING MEMORY QUEUE 


+- 


-+ 


>0E 

I 

JSBEOR 

1 

END OF REQUEST PROCESSING ANCHOR 


+— 

+ 

-+ 


>10 

I 

JSBJCA 

f 

SSB ADDRESS FOR JCA 


+- 

+ 

— + 


>12 

! 

JSBSMT 


SM TABLE SSB ADDRESS FOR JCA 


+— 

+ 

-+ 


>14 

1 

JSBNAM ! 

! 

JOB NAME 


+— 

+ 

-+ 



/ 

/ 

/ 



/ 

/ 

/ 



+- 

+ 

-+ 


>1C 

1 

JSBUID ! 

J 

USER ID OF JOB 


+- 

+ 

— + 



/ 

/ 

/ 



/ 

/ 

/ 



+- 




>24 

! 

JSBWOT 

! 

TABLE AREA JSB WAIT QUEUE LINK 


+- 

+ 

-+ 


>26 

j 

JSBVER 

I 

PTR TO SELF FOR VERIFICATION 


+- 

+ 

-+ 



FLAGS FOR FIELD: JSBFLG #04 - JOB FLAGS 

JSFVER = (X ) - BY-PASS VERIFICATION CHECKS 
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JSFACC = (.X ) - ACCOUNTING STARTED FOR JOB 

JSFBAC = (..X ) - BACKGROUND JOB 


EQUATES : 
LABEL 
JSBSIZ 


EQUATE TO VALUE DESCRIPTION 

$ >28 
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KCB 


************************************************************ 
* * 

* KIF CURRENCY BLOCK (KCB) 01/22/82 * 

* * 


* LOCATION: SYSTEM TABLE AREA * 

* * 
************************************************************ 

* THE KCB IS USED TO MAINTAIN CURRENCY INFORMATION ABOUT A 

* KEY INDEXED FILE IN USE, THE KCB IS BUFFERED ALONG WITH 

* THE IRB DESCRIBING THE I/O REQ.UEST. 

* 


* SPECIAL FIELD COMMENTS: 

* KCBKAD - FIRST TWO WORDS GIVE THE PHYSICAL RECORD NUMBER 

* OF THE logical RECORD. THE THIRD WORD IS THE 

* ID OF THE LOGICAL RECORD. 

* KCBBTP - FIRST TWO WORDS GIVE THE PHYSICAL RECORD NUMBER 

* OF THE KEY FROM WHICH THE CURRENCY WAS CREATED. 

* THE THIRD WORD IS THE LOGICAL ADDRESS OF THE KEY 

* WHEN THE PHYSICAL RECORD IS MAPPED INTO KIF 

* PROCESSING CODE. 



*- 

+ 

-* 


>02 

I 

KCBINF ! KCBKNM 

1 

CURRENCY INFORMATION CODE 


+- 

+ 

— + 

KEY NUMBER 

>04 

I 

KCBKAD 

j 

KEY ADDRESS 


+- 




>06 

1 

KCBDBK 

I 

DATA BASE KEY (3 WORDS) 


+— 

+ 

- + 


>08 

! 

FILLOO 

j 



+- 


-+ 


>0A 

I 

FILL 01 




+- 


-+ 


>0C 

i 

KCBBTP 

1 

B-TREE POINTER (3 WORDS) 


+- 

+ 

-+ 


>0E 

t 

FILL02 

1 



+- 


-+ 


>10 

I 

FILL03 

f 



+- 


-+ 


>12 

I 

KCBBES 

j 

B-TREE ENTRY SIZE 


+- 


-+ 


>14 

i 

KCBLOC ! KCBCOC 

! 

LAST OPCODE USED 


+- 


— + 

CURRENT OPCODE 


EQUATES : 
LABEL 
KCBS IZ 


EQUATE TO 


$-KCBINF 


VALUE DESCRIPTION 
>14 
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* 

* 

* 

■k 


KEY DESCRIPTOR BLOCK (KDB) 

LOCATION; STA (PART OF IRB) 


09/10/79 


kkkkkkkkkkkk'k-kkkkkkk-kkkifk-kkkkkkkk'kkkkkkkk’kkkkickkkk-kkkkkk-k'k 

* THE KDB IS PART OF A CREATE KEY INDEXED FILE I/O REQUEST 

* BRB WHICH DESCRIBES THE KEYS TO BE CREATED. 


* 

* 

* 

* 

** 


>00 

>02 

>04 

>06 

>08 


k 

I KDBOVH 

+ 

! KDBMLR 

+ 

i 

+ +- — 

! KDBNKY 

+ +--* 

! KDBOFF ! 

+ + 

/ / 

/ / 

+ + — . 


* + 


>00 

I 

KDBFGS ! 


+- 


>02 

! 

KDBO 


+- 

+ 


KDBSIZ 


* 

! OVERHEAD 
+ 

! MAX NUMBER LOGICAL RECORDS 
+ 
j 

+ 

! NUMBER OF KEYS 
+ 

! SPACE FOR MAXIMUM # KEYS 
+ 

/ 

/ 

+ 

DESCRIPTION OF ONE KEY 
* 

! FLAGS 

+ NUMBER OF CHARACTERS IN KEY 

! KEY OFFSET IN RECORD 
+ 


FLAGS FOR FIELD: KDBFGS #00 - FLAGS 



= 

(XXX 

. . . . ) - *** 

RE 

SERVED 

* * * 

KDBPLG 

= 

(. 

.X 

. . . . ) - BIT 

3 

SET 

IF 

PARTIAL LOGGING 

KDB33 

= 

(. 


. . . . ) - BIT 

4 

SET 

IF 

sequential KIF 

KDBOFG 

= 

(. 


. . . . ) - BIT 

5 

SET 

IF 

KEY IS OPTIONAL 

KDBSFG 

= 

(. 


. . . . ) - BIT 

6 

SET 

IF 

SEQUENTIAL CMNDS 

KDBDFG 

= 

(. 


. . . . ) - BIT 

7 

SET 

IF 

DUPLICATES OK 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 

KDBMKY 

14 

>0E 

MAXIMUM 

# OF KEYS IN FILE 

KDBMSZ 

100 

>64 

MAXIMUM 

KEY SIZE 

KDBNXT 

$ 

>04 

SIZE OF 

KEY DESCRIPTOR 
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KDP 


***************************** *•* *************************** 
* * 

* KEY INDEXED FILE KEY DESCRIPTOR RECORD(KDR) 09/09/83 * 

* * 

* LOCATION: DISK RESIDENT STRUCTURE * 

********************************************************** 

* THE KDR DESCRIBES THE KEYS OF A KEY INDEXED FILE, THE 

* FIELD AT KDROFF IS ONE OR MORE REPLICATIONS OF THE 

* FIELDS BEGINNING AT KDRFGS. 




>00 

I 

KDRHKC 

1 


+- 

+ 


>02 

! 

KDRHKV 

1 


+- 

+ 

+ 

>04 

! 

FILLOO 

1 


+— 


+ 

>06 

1 

KDRNKY 

j 


+— 


+ 

>08 

1 

KDROFF ! 

t 


+- 


f. 


/ / / 

/ / / 

+ + + 


>40 

I 

KDRCD 

1 

1 

>42 

! 


! 

! 

>44 

I 


1 

JL 

! 

>46 

T — 

f 

+ - 

KDRSEQ 

! 

-+- 

KDRCCT ! 


HASH KEY COUNT 
HASH KEY VALUE 
(WORD COPIED FROM KDB) 

NUMBER OF KEYS 

SPACE FOR MAXIMUM # KEYS 

CREATION DATE AND TIME USED 

CONCATENATED SET SEQUENCE NUM. 
TOTAL CONCAT. FILES IN SET 


FLAGS DESCRIPTION (NOT A VARIANT) 
* * 

>00 ! KDRFGS ! KDRSIZ ! FLAGS 

+ + + // CHARS IN KEY 

>02 I KDRO ! KEY OFFSET IN RECORD 

+ + + 


FLAGS FOR FIELD: KDRFGS #00 

= (XXX ) - 

KDRPFG = ( , . . X ) - 

KDR33 = (..,.X ) - 

KDROFG = ( X ) - 

KDRSFG = ( X ) - 

KDRDFG = ( X ) - 


FLAGS 

*** reserved *** 

BIT 3 SET IF PARTIAL LOGGING 
BIT 4 SET IF SEQUENTIAL KI F 
BIT 5 SET IF KEY IS OPTIONAL 
BIT 6 SET IF SEQUENTIAL CMNDS 
BIT 7 SET IF DUPLICATES OK 
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EQUATES ; 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


KDRMKY 

14 

>0E 

MAX # OF KEYS 

IN FILE 

KDRMSZ 

100 

>64 

MAX KEY SIZE 


KDRNXT 

$ 

>04 

SIZE OF KEY DE 

SCRIPTOR 
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************************************************************ 
* * 

* KIF INFORMATION BLOCK (KIB) 02/26/80 * 

* * 

* LOCATION: DISK AND BUFFER SEGMENT * 

************************************************************ 

* THE KIB DESCRIBES A KEY INDEXED FILE DATA BLOCK. 

* 

* SPECIAL FIELD COMMENTS: 

* KIBBLK - THE PHYSICAL RECORD NUMBER OF THIS BLOCK. THIS 

* FIELD IS MAINTAINED SO THAT IF A SYSTEM CRASH 

* OCCURS WHILE THIS BLOCK IS BEING MODIFIED, THE 

* LOGGED IMAGE CAN BE RESTORED TO THE CORRECT FILE 

* RECORD. 

* KIBCMD - THE OPCODE OF THE CURRENT COMMAND. THIS IS 

* MAINTAINED FOR LOGGING PURPOSES. 

* KIBSR - THE NUMBER OF BYTES REMAINING IN THE PHYSICAL 

* RECORD. 

* KIBFCB - THIS FIELD IS USED TO LINK THE BLOCK ON THE FREE 

* BLOCK CHAIN. 

* KIBRSZ - THE SIZE IN BYTES OF THE FIRST LOGICAL RECORD 

* INCLUDING THIS WORD. 


* — — _* 


>00 

1 

KIBBLK 

f 


+ 


+ 

>02 

! 


j 


+ — " " 

+ 

"• — — — 

>04 

I 

KIBCMD 

1 


+ 


— — — — + 

>06 

I 

KIBSR 

f 


+ 


+ 

>08 

I 

KIBFCB 

j 





+ 

>0A 

J 


1 


+ 

+ 

— — — — + 

>0C 

1 

KIBHID 

1 



+ 

+ 

>0E 

I 

KIBRSZ 

! 


+ 


+ 

>10 

I 

KIBRID 

! 


H 


-1- 


EQUATES : 

LABEL EQUATE TO VALUE 


KIBOFB $ >08 


BLOCK NUMBER 

COMMAND NUMBER 

SPACE REMAINING IN BYTES 

FREE CHAIN POINTER 

HIGHEST logical RECORD ID USED 
RECORD SIZE OF 1ST RECORD 
ID OF FIRST LOGICAL RECORD 

DESCRIPTION 

OVERFLOW BLOCK POINTER 
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* KIF TASK AREA 


(KIT) 


01/21/82 * 


* LOCATION: SYSTEM TABLE AREA * 

* (USED ONLY BY ASSEMBLY LANGUAGE CODE) * 

************************************************************ 

* THE KIT IS ATTACHED TO THE FILE MANAGEMENT WORK AREA ( FWA ) 

* FOR ADDITIONAL WORKING STORAGE FOR KIF PROCESSING. IT 

* INCLUDES INFORMATION ABOUT THE CURRENT REQUEST, THE STATE 

* OF THE FILE, AND SEVERAL FIELDS OF THE FCB TO MINIMIZE 

* MAPPING DURING PROCESSING. 

************************************************************ 


* FILE MANAGER WORK AREA (FWA) 01/21/82 * 

* * 

* LOCATION; SYSTEM AREA * 

************************************************************ 


* THE FWA IS USED BY FILE MANAGEMENT AND BY KIF MANAGEMENT 

* AS A GENERAL WORK AREA. R15 POINTS TO THE FWA. 


* 1 * 


>00 

1 

FWAWP ! 

! 

WORKSPACE USED BY FM 


+- 

+ 

* ■■ ■■ 




/ 

/ 

/ 




/ 

/ 

/ 




+- 


+ 



>20 

1 

FWAFLG 

j 

MIDDLE 

SEGMENT FLAGS 


+- 

+ 

+ 



>22 

f 

FWATCT 

f 

MULTIRECORD CHARS TRANSFERRED 


+- 


* — — -f- 



>24 

j 

FWAOAD 

1 

CURRENT OVERLAY AREA ADDRESS 


+- 

+ 

+ 



>26 

f 

FWAPC 

1 

SAVED 

PROGRAM COUNTER 


+— 

+ 

— — — — 



>28 

! 

FWAXWP 

1 

BLWP VECTOR FOR RETURNING 




+ 



>2A 

I 

FWAXPC 

1 




+- 


+ 



>2C 

i 

FWABN 

j 

SAVED 

RPBBN (2 WORDS) 


+- 

+ 

+ 



>2E 

1 


f 




+- 

+ 




>30 

I 

FWAOCB 

1 

SAVED 

RPBOCB 


+- 

+ 

+ 



>32 

I 

FWALFG 

f 

SAVED 

LDT FLAGS 




+ 



>34 

I 

FWAFFC 

! 

FIRST 

FCB FOR CC FILES 


+ — 

+ 

“ — -J- 



>36 

I 

FWAFMT 

I 

SSB FOR THE FMT WITH THE FCB 


+- 

+ 

-f- 
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KIT 

>38 

f 

FWAFCB 

1 

FCB ADDRESS IN THE FMT 


4— 

+ 

-+ 


>3A 

i 

FWABST 

1 

SMT SSB ADDR FOR BUFFER 


+- 

+ 

-+ 


>3C 

1 

FWABSB 

1 

SSB ADDR FOR BUFFER 


+- 


-+ 


>3E 

I 

FWAPRS 

I 

PHYSICAL RECORD SIZE 


+- 

+ 

“+ 


>40 

! 

FWAUBT 

! 

USER BUFFER SMT SSB ADDR 


+- 


■•+ 


>42 

! 

FWAUBS 

! 

USER BUFFER SSB ADDRESS 


+- 

+ 

-+ 


>44 

1 

FWAUBO 

1 

USER BUFFER OFFSET 


+- 

+ 

-+ 


>46 

f 

FWAUBL 

i 

USER BUFFER LENGTH 


+- 

+ 

-+ 


>48 

I 

FWAFMB 

! 

FMT BIAS 


+- 

+ 

-+ 


>4A 

1 

FWARNl 

! 

RECORD /if RELATIVE TO CURRENT 


+- 


-+ 


>4C 

i 

FWARN2 

1 

FILE OF CONCATENATED SET 


+- 

+ 

— h 


>4E 

1 

FWAOOB 

1 

OLD OFFSET IN USER BUFFER 


+- 


“ + 


>50 

1 

FWAUBR 

f 

BUFFER LENGTH REMAINING 


+- 

+ 

“+ 


>52 

1 

FWAFFG 

! 

FILE MGR FLAGS 


+- 

+ , 

-+ 


>54 

! 

FWASTK ! 

! 

STACK AREA 


+— 

+ 

-+ 



/ 

/ 

/ 



/ 

/ 

/ 



+- 


-+ 





TEMPORARY KIF STORAGE IN TASK AREA 




-* 


>54 

I 

FILLOl ! 

f 

KIF STACK 


+- 

+ 

-+ 



/ 

/ 

/ 



/ 

/ 

/ 



+- 


- + 


>0130 

j 

KITBKM 

I 

LOGICAL BLOCK END OF MEDIUM 


+- 


“+ 


>0132 

j 


1 



+- 


-+ 


>0134 

I 

KITCMD 

f 

CURRENT COMMAND NUMBER 


+- 

+ 

“+ 


>0136 

1 

KITEBQ 

j 

EMPTY BLOCK QUEUE HEAD 


+- 

+ 

-+ 


>0138 

f 


1 



+- 

+ 

“+ 


>013A 

1 

KITCLB 

1 

CURRENT LOG BLOCK 


+- 


“+ 
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>013C 

j 

KITFBQ 

i 

>013E 

“T — 

! 


j 

>0140 

T — 

f 

KITBTR 

j 

>0142 

f 

KITKDB ! 

J 


/ 

/ 

/ 

/ 

/ 

/ 

>017C 

T" — 

I 

KBUFIA 

I 

>017E 

f 

KBUF2A 

! 

>0180 

1 

KBUF3A 

! 

>0182 

j 

KEYNUM 

I 

>0184 

"r“ 

f 

KEYSZ 

1 

>0186 

“r — 

1 

BTSTK ! 

I 


“T"* 

/ 

/ 

/ 

/ 

/ 

/ 

>01C2 

“T — 

j 

BTSTKA 

1 

>01C4 

f 

BTSPTR 

f 

>01C6 

f 

NEIBTS 

I 

>01C8 

“T — 

f 

TS 1L2 

j 

>01CA 

"T — 

f 

T1L2A 

1 

>01CC 

f 

TS1L2 A 

j 

>01CE 

T““ 

f 

TS 1L2B 

j 

>01 DO 

T*“ 

! 

TS1L2C 

j 

>01 D2 

! 

T1L2CA 

j 

>01 D4 

f 

TS 1L2D 

1 

>01D6 

"r"“ 

j 

T1L2DA 

f 

>01D8 

•T"* 

J 

TS 1L4 

I 

>01 DA 

■r“ 

f 


f 

>01 DC 

"T 

; 

T1L4A 

f 


FREE BLOCK QUEUE HEAD 

B-TREE ROOTS 

KDB OF CURRENT REQUEST 

ADDRESS OF FIRST KEY BUFFER 
ADDRESS OF SECOND KEY BUFFER 
ADDRESS OF THIRD KEY BUFFER 
KEY # OF KEY CURRENTLY USING 
SIZE (CHARS) OF THIS KEY 
B-TREE STACK 

ADDR 1ST ENTRY OF B-TREE STACK 
ADDR 1ST UNUSED B-T STACK ENTRY 
NUMBER ENTRIES IN B-TREE STACK 
1 WORD OF LEVEL 1 TEMP STORAGE 
ADDRESS OF TS1L4 
1 WORD OF LEVEL 1 TEMP STORAGE 

1 WORD OF LEVEL 1 TEMP STORAGE 

1 WORD OF LEVEL 1 TEMP STORAGE 

ADDRESS OF TS1L2C 

1 WORD OF LEVEL 1 TEMP STORAGE 
ADDRESS OF TS1L2D 

2 WORDS OF LEVEL 1 TEMP STORAGE 

ADDRESS OF TSILY 
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KIT 


>01 DE 

+ — 

I 

TS1L4A 

— + 

f 

>01E0 

f 


f 

>01E2 

*1" — 

t 

T1L4AA 

I 

>01E4 

f 

TS 1L4B 

i 

>01E6 

I 


“ —-f- 

I 

>01E8 

f 

T1L4BA 

1 

>01EA 

1 

TS 1L6 

1 

. ..4- 

>01 EC 

I 


{ 

>01EE 

“r“ — 

f 


— T“ 

I 

>01F0 

I 

T1L6A 

; 

^ —4. 

>01F2 

1 

TS2L2 

I 

._.4. 

>01F A 

j 

T2L2A 

t 

•• .4- 

>01F6 

f 

TS2L4 

j 

— «»4> 

>01F8 

t 


I 

JL 

>01FA 

^mmmm 

j 

T2L4A 

t 

...4. 

>01FC 

• 

f 

TS2L4A 

f 

— ..4. 

>01FE 

T" — *" 

f 


I 

^ ^4. 

>0200 

j 

T2L4AA 

f 

— «.4- 

>0202 

? 

TS2L4B 

1 

^ -4- 

>0204 

J 

T2L4 BA 

J 

_-.4. 

>0206 

“T — 

J 

J 

>0208 

•r — "■ 

1 

TS2L4C 

I 

. <^4- 

>020A 

•T" — 

j 


f 

— -4- 

>020C 

J 

T2L4CA 

} 

^ .4- 

>020E 

"T— ~ 

I 

RQDBKA 

j 

>0210 

T — — 

1 

+ 

RQBTPA 

mm 

j 

+ 
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2 WORDS 

OF 

LEVEL 1 

TEMP 

STORAGE 

ADDRESS 

OF 

TS1L4A 



2 WORDS 

OF 

LEVEL 1 

TEMP 

STORAGE 

ADDRESS 

OF 

TS1L4B 



3 WORDS 

OF 

LEVEL 1 

TEMP 

STORAGE 

ADDRESS 

OF 

TS1L6 



1 WORD 

OF 

LEVEL 2 

TEMP 

STORAGE 

ADDRESS 

OF 

TS2L2 



2 WORDS 

OF 

LEVEL 2 

TEMP 

STORAGE 

ADDRESS 

OF 

TS2L4 



2 WORDS 

OF 

LEVEL 2 

TEMP 

STORAGE 

ADDRESS 

OF 

TS2L4A 



2 WORDS 

OF 

LEVEL 2 

TEMP 

STORAGE 

ADDRESS 

OF 

TS2L4B 



2 WORDS 

OF 

LEVEL 2 

TEMP 

STORAGE 

ADDRESS 

OF 

TS2L4C 



ADDRESS 

OF 

KCBDBK 



ADDRESS 

OF 

KCBBTP 
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>0212 ! BTDBKA ! 

+ + + 

>0214 ! FDRCFG ! 

+ + + 

>0216 ! BTSPLT ! 

H — — — + — — — — _ — — — — + 

>0218 ! TBTP ! ! 

>021A ! ! ! 


+ + + 

>021C ! ! ! 


>021 E 

+- 

I 

ATBTP 

-+ 

1 

>0220 

f 

TDBK ! 

f 

-.4- 

>0222 

•r“ 

! 


I 

mmM. 

>0224 

f 


! 

m4- 

>0226 

T“* 

f 

ATDBK 

I 

>0228 

T* 

j 

SBLK 

j 

>022A 

“T* 

! 


i 

>022C 

f 

ASBLK ! 

! 

>022E 

“T — 

J 

LEAFFL 1 

f 

>0230 

T""" 

f 

RWSAV8 

f 

>0232 

”r"“ 

I 

RRPDC 

! 

mmJL 

>0234 

I 

RRPDFL 

j 

— 4. 

>0236 

f 

RQSAVE 

I 

>0238 

"T" 

I 

CWSRO ! FILL02 

“"T 

f 

m4- 

>023A 

"T — 

J 

CWSRl 

I 

>023C 

"T — 

f 

CWSR2 

1 

>023E 

f 

CWSR3 

! 

.4- 

>0240 

f 

CWSR4 

I 

«4- 

>0242 

T — 

1 

+ - 

CWSR5 

-f- 

I 

— + 


ADDRESS OF BTBDBK 
FDR CHANGE FLAG 
B-TREE SPLIT FLAG 
TEMPORARY B-TREE POINTER 

ADR TEMPORARY B-TREE POINTER 
TEMPORARY DATA BASE KEY 

ADR OF temporary DATA BASE KEY 
SAVED SUCCESSOR BLOCK NUMBER 

ADR SAVED SUCCESSOR BLK NUMBER 

SAVED LEAF FLAG 

SAVE R8 HERE 

DUP COUNT OF DUP WANTED 

DUPLICATES FLAG 

ORIG RQ FOR PASSIVE READS 

ALT SEQ=>FF, STD SEQ=>00 
CONV REQ FLAG (BIT 8) 
STORAGE FOR KEYl ADDRESS 

STORAGE FOR KEY2 ADDRESS 

STORAGE FOR KEY LENGTH 

KMCNV BASE DATA ADDRESS 

KMUCV BASE DATA ADDRESS 


FLAGS FOR FIELD: FWAFFG #52 - FILE MGR FLAGS 
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FWAPOP = (X ) - 

FWAQW = ( .X ). - 

EQUATES : 

LABEL EQUATE TO VALUE 

FWASIZ $ >F4 

MAXSSZ 9 >09 

KITSIZ $ >244 


PASSIVE OPERATION FLAG 
QUEUED TO WAITING QUEUE IN FCB 


DESCRIPTION 


SIZE OF FWA INCLUDING WSP 
ONLY 9 STACK ENTRIES ALLOWED 
SIZE INCLUDING WORKSPACE 
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***************************************************:%******** 
* * 


* KEYBOARD STATUS BLOCK (KSB) 

* 


09/28/79 * 

* 


* LOCATION: SYSTEM AREA * 


* THE KSB IS APPENDED TO A PHYSICAL DEVICE TABLE (PDT) FOR 

* A KEYBOARD DEVICE. IT IS USED BY THE DEVICE SERVICE 

* ROUTINE (DSR) AS A WORKSPACE WHILE HANDLING THE KEYBOARD. 


CHARACTER BUFFER LENGTH 


— — -I- — — — — — — A 


>00 

1 

KSBPDT 

f 

. ..I- 

>02 

f 

KSBQOC 

1 

>04 

T*" 

f 

KSBQIP 

I 

>06 

“T"* 

f 

KSBQOP 

f 

- — 4- 

>08 

"T — 

I 

KSBQEP 

j 

- «4- 

>0A 

"r"“ 

1 

KSBCRQ 

j 

>0C 

“T"" 

f 

KSBFL ! KSBSN 

1 

» *4. 

>0E 

J 

KSBR7 

! 

mmm^ 

>10 

•r — 

1 

KSBTSB 

1 

. ^4. 

>12 

•r “ 

f 

KSBR9 

I 

• «.4. 

>14 

"T — 

J 

KSBRIO 

1 

- «4- 

>16 

"T — 

f 

KSBRl 1 

f 

- — 4- 

>18 

"T — 

I 

KSBCRU 

f 

- -4- 

>1A 

“r“ 

f 

KSBR13 

1 

• — 4- 

>1C 

”r"“ 

! 

KSBR14 

f 

- — 4- 

>1E 

+— 

f 

+- 

KSBRl 5 

1 

“ — + 


FLAGS FOR FIELD: KSBFL //OC 


RO - PDT POINTER 

RI - QUEUE OUTPUT COUNT 

R2 - QUEUE INPUT POINTER 

R3 - QUEUE OUTPUT POINTER 

R4 - QUEUE END POINTER 

R5 - GET char REQUEST QUEUE 

R6 - KSB FLAGS 

- STATION NUMBER 
R7 - SCRATCH ' 

R8 - TSB ADDRESS OF CHAR OWNER 

R9 - SCRATCH 

RIO - SCRATCH 

Rll - SCRATCH 

R12 ~ CRU BASE 

R13 - SAVED WORKSPACE POINTER 
R14 - SAVED PROGRAM COUNTER 
R15 - SAVED STATUS 

- R6 - KSB FLAGS 


KSBCHM = (X ) - CHARACTER MODE 

KSBCIE = (.X ) - SCI ENABLED 

KSBRCM = (..X ) - RECORD MODE 

KSBCIB = (...X ) - SCI BID IN PROCESS 
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KSBICP = (....X ) - SCI ACTIVE 

KSBSET = ( X ) - COMMAND I/O HOLD 

KSBKIO = ( X ) - COMMAND I/O ABORT 

KSBBRK = ( X ) - DEACTIVATE BREAK KEY 


EQUATES ; 

LABEL EQUATE TO VALUE DESCRIPTION 


KSBCBL 6 >06 CHARACTER BUFFER LENGTH 

KSBSIZ $ >20 
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**:%************ * * * * * * * * ***********:fc*************:fc********:«c** 
* * 

* LOGICAL DEVICE TABLE (LDT) 01/27/83 * 

* * 

* LOCATION: SYSTEM AREA AND JCA * 

* THE LDT CONTAINS INFORMATION DESCRIBING AN I/O RESOURCE TO 

* WHICH A LOGICAL UNIT NUMBER (LUNO) HAS BEEN ASSIGNED. IT 

* INCLUDES TYPE FLAGS, OWNERSHIP, AND STATE INFORMATION. 

** BEGINNING PACKED RECORD LDT 


■k -I * 

>00 ! LDTLDT ! 

+ + + 

>02 ! LDTIOC ! LDTLUN ! 

+ + + 


LINK TO NEXT LDT 

INITIATE I/O COUNT 

LOGICAL UNIT NUMBER 


* + 

>04 ! LDTTYP ! LDTTF 

>06 ! LDTFLG 

>08 ! LDTRLK 

+ + 

>0A ! LDTTSB 

+ + 

>0C ! LDTJSB 

+ + 


.* 

I 

•+ 

! 

•+ 

j 

•+ 

I 

■+ 

I 

■+ 


I/O RESOURCE TYPE 

FLAGS FOR LDT TYPE (SEE LDTXFL) 
FLAGS 

RESOURCE LINK: FCA, PDT OR CCB 
OWNER TSB LIST ANCHOR 
OWNER JSB ADDRESS 


* 

>0E ! 


LDTSID 


DEVICE, CHANNEL LDT 
.* 


SESSION ID 


>0E ! 

+■ 

>10 ! 

+■ 

>12 ! 


LDTFMT 

LDTFCB 

LDTCAR 


FILE LDT 
.* 


SSB FOR THE FMT 

FCB ADDRESS IN THE FMT 

COMPOSITE ACCESS RIGHTS 


* 

>04 ! 

>14 SIZE 


LDTXFL 


RESOURCE TYPE / FLAGS 


** END OF PACKED RECORD 
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FLAGS FOR FIELD: LDTFLG #06 - FLAGS 

LDFDEL = (X ) - LDT IS DELETE PROTECTED 

LDFFWT = (.X .....) - FORCED (IMMEDIATE) WRITE BIT 

LDFCBA = (..X ) - CREATED BY ASSIGN BIT 

LDFNUS = (. ..X ) - LDT IS CURRENTLY NON-USABLE 

LDFPRM = (....X ) - PARAMETERS ARE PRESENT 

LDFUBI = ( X ) - UNBLOCKED( 1 )/BLOCKED( 0) OPEN 

LDFACU = ( XX ) - ACCESS PRIV. IN USE 

* , 00 = EXCLUSIVE WRITE 

* 01 = EXCLUSIVE ALL 

* 10 = shared 

* 11 = READ ONLY 

LDFSCl = ( XX ) - LDT SCOPE (TASK, JOB, GLOBAL) 

* 00 = task-local 

* 01 = JOB-LOCAL 

* 10 = GLOBAL 

* 11 = shared 

LDFDWE = ( X ) - deferred WRITE ERROR 

LDFVNT = ( X....) - EVENTS REQUESTED (KB DEVICES) 

LDFUSD = ( X...) - LDT HAS BEEN USED 

LDFDIA = ( X..) - DIAGNOSTIC STATE 

= ( XX) - *** RESERVED *** 

FLAGS FOR FIELD: LDTCAR #12 - COMPOSITE ACCESS RIGHTS 

LDFRDF = (X ) - READ ACCESS FLAG 

LDFWRF = (.X ) - WRITE ACCESS FLAG 

LDFDLF = (..X ) - DELETE ACCESS FLAG 

LDFEXF = (...X ) - EXECUTE ACCESS FLAG 

LDFCTF = (....X ) - CONTROL ACCESS FLAG 

= ( XXXXXXXXXXX) - **RESERVED** 

FLAGS FOR FIELD: LDTXFL #04 - RESOURCE TYPE / FLAGS 

= (XXXXXXXX ) - ** ACTUALLY LDTTYP FIELD ** 

LDFJLO = ( X ) - l = JOB LEVEL OPEN 

= ( XX ) - **RESERVED** 

LDFVD = ( X....) - LDT FOR A VIRTUAL DEVICE 

LDFREM = ( X...) - LDT FOR REMOTE RESOURCE 

LDFCHN = ( X..) - LDT FOR CHANNEL 

LDFDEV = ( X.) - LDT FOR DEVICE 

LDFFIL = ( X) - LDT FOR FILE 

* 

* VALUES FOR I/O RESOURCE TYPE (FIELD LDTTYP) 

* 

* 

EQUATES : 
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LABEL EQUATE TO VALUE DESCRIPTION 


LDFACM 

>0300 

>300 

LDFSCM 

>00C0 

>C0 

LDFMM 

LDFDWE 

>0A 

LDTSZl 

$ 

>0E 

LDTSZ2 

$ 

>10 

LDTFSZ 

$ 

>14 

LDTRES 

0 

>00 

LDTSEQ 

1 

>01 

LDTRR 

2 

>02 

LDTKIF 

3 

>03 

LDTDIR 

4 

>04 

LDTPRG 

5 

>05 

LDTIMG 

6 

>06 

LDTDMY 

0 

>00 

LDTSD 

1 

>01 

LDTKSR 

2 

>02 

LDTASR 

3 

>03 

LDTCS 

4 

>04 

LDTRS2 

5 

>05 

LDTDK 

6 

>06 

LDTDS 

7 

>07 

LDTMT 

8 

>08 

LDTTPD 

9 

>09 

LDTVl 1 

>A 

>0A 

LDTLPS 

>B 

>0B 

LDTLPP 

>C 

>0C 

LDTC3Q 

>D 

>0D 

LDTCOM 

>E 

>0E 

LDTIND 

>F 

>0F 

LDTCR 

>10 

>10 

LDT940 

>11 

>11 

LDT931 

>12 

>12 

LDTEN 

>13 

>13 

LDTBCM 

>14 

>14 

LDTVT 

>15 

>15 


ACCESS PRIV. BIT MASK 
SCOPE BIT MASK 
MAGIC MODE FOR EVDT 

DEVICE, CHANNEL LDT SIZE 

FILE LDT SIZE 

RESERVED 

SEQUENTIAL 

RELATIVE RECORD 

KEY INDEX 

DIRECTORY 

PROGRAM 

IMAGE 

DUMY 

SPECIAL DEVICES 

KSR 

ASR 

CASSETTE 

RESERVED 

SINGLE density DISKETTE 
DISK 

MAG TAPE ( 979 , CARTRIDGE) 
820 

911 VDT 

LINE PRINTER (SERIAL) 
LINE PRINTER (PARALLEL) 
COMM 9903 (FCCC) 

COMM I/F 

INDUSTRIAL DEVICES 

CARD READER 

940 EVT 

931 EVT 

ETHERNET 

BCAIM 

virtual TERMINAL BASE 
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icit^‘k‘kitickick'kifk‘kifkit:k^'ick‘kick-k-k-k-k-k-k'ic-kifkic-k‘kic:kie‘k-k-k-kit'ifk'k‘kifk'kickicitifkick 


* 

* LOG FILE DEFINITION (LFD) 

* 


* 

04/26/82 * 

* 


* LOCATION: SYSTEM ROOT * 


* THE LFD IS BUILT DURING SYSTEM GENERATION AND IS USED TO 

* KEEP TRACK OF THE STATE OF THE SYSTEM LOG OPTIONS. 


* H * 

>00 ! LFDFLG ! LFDERR ! FLAGS 

+ + + ERROR BYTE FOR RECREATE TASK 

>02 ! LFDMAX ! MAX MESSAGE COUNT (0 = NONE) 

+ + + 

>04 ! LFDTID ! LFDTDU ! TASK ID TO BID FOR FULL FILES 

+ + + USER TASK ID TO BID ON FULL 

>06 ! LFDDNM ! ! LOG DEVICE NAME (' '= NONE) 

>08 ! ! ! 

H 1 — -f- 

>0A ! LFDFNl ! ! FILENAME 1 

H 1 1- 

/ / / 

/ / / 

— — — — 

>12 ! LFDFN2 ! ! FILENAME 2 

+ — + + 

/ / / 

/ / / 

— — — — — ~ — 

>1A ! LFDALC ! LOG FILE ALLOCATION 

H 1 * H 

>1C ! LFDLUN ! ! LUNOS 

— — — — — — — H — — — — — — — — — — -f- 

FLAGS FOR FIELD: LFDFLG //OO - FLAGS 

LDFFDS = (X ) - FILES DISABLED 

LDFDDS = (.X ) - DEVICE DISABLED 

LDF2ND = (..X ) - CURRENTLY USING 2ND FILE 

LDFCSH = (...X ) ~ CRASH FILE PROCESSED 

LDFRCR = (....X ) - RECREATE FILES 

LDFIMW = ( X ) - FILES ARE IMMEDIATE WRITE 

LDFSBE = ( X ) - SUPPRESS BID ERROR LOGGING 
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EQUATES: 

LABEL EQUATE TO VALUE 


LFDSIZ 


>1E 


DESCRIPTION 
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* * 

* LINE PRINTER PDT EXTENSION (LPD) 04/21/82 * 

* * 

* LOCATION: SYSTEM AREA * 

************************************************************ 

* THE LPD IS AN EXTENSION TO THE PHYSICAL DEVICE TABLE (PDT) 

* FOR A LINE PRINTER. IT CONTAINS POINTERS AND FLAGS USED 

* BY THE LINE PRINTER DEVICE SERVICE ROUTINE (DSR). 




>00 

! LPDIFF 

f 

INTERFACE FLAGS 

>02 

! LPDQCC 

j 

QUEUE 

CHARACTER COUNT 

>04 

! LPDQIP 

1 

QUEUE 

INPUT POINTER 

>06 

! LPDQOP 

I 

QUEUE 

OUTPUT POINTER 

>08 

! LPDQEP 

f 

•. 4 . 

QUEUE 

END POINTER 

>0A 

! LPDBUF ! 

1 

CHARACTER BUFFER 

>0C 

! ! 

! 



>0E 

! LPDQSZ 

1 

CHARACTER QUEUE SIZE 

>10 

! LPDSPX ! LPDSPR 

— T 

1 

— + 

TRANSMIT SPEED 

RECEIVE SPEED 


FLAGS FOR FIELD: LPDIFF #00 - INTERFACE FLAGS 


LPFIF 

LPFUC 

LPFBSY 

LPF902 

LPFEOR 

* 

* 


(X ) - INTERFACE (0<=DM; 0>EIA) 

(.X ) - UPPERCASE ONLY (0 = YES; l = NO) 

(..X ) - "RO" TERMINAL BUSY(0 = NO ,1=YES) 

(...X ) “ 9902 INTERFACE FLAG 

(....X ) - END-OF-RECORD FLAG 

1 = SAFE TO ISSUE ENDRCD 
0 = DON'T ISSUE ENDRCD 
( XXXXXXXXXXX) - RESERVED 


EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


LPDSIZ 


>12 


2270512-9701 


22-103 


Structure Pictures 



LSE 


DNOS System Design Document 


* * 

* LOAD SEGMENT ENTRY (LSE) 04/04/79 * 

* * 

* LOCATION; JCA * 

**************************:fc****************** * * ************* 

* THE LSE DESCRIBES A SEGMENT WHICH IS LOADED INTO MEMORY 

* WHILE THIS TASK IS RUNNING, BUT MAY NOT CURRENTLY BE MAPPED 

* IN TO THE TASK. IT IS LINKED TO THE TSB. 


* 1 * 


>00 

f 

LSELSE 

f 


+ 

+ 


>02 

t 

LSESSB 

j 


+ 

+ 

— — — — + 

>04 

i 

LSESMT 

! 


-1 





LINK TO NEXT LOAD SEGMENT ENTRY 
SSB ADDRESS OF LOADED SEGMENT 
SM TABLE AREA SSB ADDR. 


EQUATES : 
LABEL 
LSESIZ 


EQUATE TO 


$ 


VALUE DESCRIPTION 


>06 
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* 

* MASTER READ/MASTER WRITE 

* 

* LOCATION: TASK 

* 

*************************** 


****** * * ************************* 

* 

BUFFER (MRB) 04/04/83 * 

* 

AREA * 

* 

********************************* 


* THE MRB IS A DESCRIPTION OF THE DATA BUFFER RETURNED TO A 

* CHANNEL OWNER TASK IN ITS MASTER READ BUFFER. THIS SAME 

* BUFFER STRUCTURE IS USED IN THE MASTER WRITE OPERATION OF 

* THE OWNER TASK. ALL BUFFER POINTERS IN THE MRB ARE 

* RELATIVE OFFSETS FROM THE BEGINNING OF THE MRB, RATHER 

* THAN BEING ABSOLUTE ADDRESSES. 

* MRB VARIANTS ARE PROVIDED FOR THE MAJOR TYPES OF I/O CALL 

* BLOCKS: BASIC FILE I/O, I/O WITH REPLY INFORMATION, I/O 

* WITH VALIDATION, VDT EXTENSIONS, AND UTILITY OPERATIONS. 

* THERE IS ALSO A VARIANT FOR ABORT I/O CALLS. 


* 


** BEGINNING PACKED RECORD MRB 


* — — _. — .* 

>00 ! MRBSID ! SECURITY INFORMATION (SESSION ID) 

~ ~ ~+ “ ~ ~ ~ 

>02 ! MRBRCB ! REQUESTOR CALL BLOCK ADDRESS 

H 1 — —- 1 - 

>04 ! MRBTSB ! REQUESTOR TSB ADDRESS 

+ + — + 

>06 ! MRBJSB ! REQUESTOR JSB ADDRESS 

-j — -f- 

>08 ! MRBSSI ! SECURITY INFORMATION (QUEUE ADDR) 

+ + + 

>0A ! MRBSOC ! MRBEC ! SVC OPERATION CODE 

+ + ._+ SVC RETURN (ERROR) CODE 

ABORT I/O VARIANT 

* + 

>0C ! MRBABF ! MRBABL ! FLAGS 

+ + + LOGICAL UNIT NUMBER 

I/O VARIANTS 

* — I 

>0C ! MRBOC ! MRBLUN ! SUB-OPERATION CODE 

+ + + LOGICAL UNIT NUMBER 

>0E ! MRBSFL ! MRBUFL ! SYSTEM FLAGS 

+ + + REQUESTOR (USER) FLAGS 

CDE NUMBER WITHIN CDT 

* 1 * 

>10 ! FILL02 ! MRBSEG ! **** RESERVED **** 

+ + + SEGMENT IDENTIFIER 

>12 ! MRBNAM ! ! DEVICE NAME 
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+ + + 



/ 

/ 

/ 

/ 

/ 

/ 

>1A 

I 

FILL03 

1 

>1C 

j 

MRBNUM 

j 

>1E 

I 

MRBDFL 

j 

>20 

! 

MRBBUF 

+ 

1 


RESERVED 
DEVICE NUMBER 
DIOU FLAGS 

PARAMETER BUFFER ADDRESS 


I/O AND lOU VARIANTS 

it — I 


>10 

I 

MRBDBA 

j 

BUFFER 

ADDR 

( OFFSET 

TO BUFFER) 

>12 

1 

MRBICC 

j 

INPUT 

CHAR 

COUNT / 

ACTUAL OUTPUT 

>14 

I 

MRBOCC 

+ 

1 

OUTPUT 

CHAR 

COUNT / 

ACTUAL INPUT 


DISK I/O VARIANTS 

k 1 k 

>16 ! MRBTRK ! TRACK ADDRESS 

H — — — — — — — — — — — — — 

>18 ! MRBSPR ! MRBSCT ! SECTORS PER RECORD 
+ + + SECTOR NUMBER 


k 1 k 


>16 

J 

MRBADU 

1 

ADU NUMBER 

>18 

1 

MRBOFF 

J. 

1 

SECTOR OFFSET INTO ADU 


T — " 




>16 

* 

1 

+ 

MRBRPY 

TERMINAL I/O BLOCK WITH REPLY 

! REPLY BLOCK ADDRESS (OFFSET) 

>18 

f 

MRBRES 

1 

(EXTRA WORD BUFFERED) 

>1A 

! 

MRBRPA 

! 

REPLY BUFFER ADDR (OFFSET) 

>1C 

I 

MRBRIC 

f 

REPLY INPUT COUNT FROM REQUESTOR 

>1E 

f 

MRBROC 

1 

REPLY OUTPUT COUNT FOR REQUESTOR 







■fr 


VDT 

« — — — ^ 

READ BLOCK WITH VDT EXTENSION 

>16 

J 

+ 

MRBROV 

+ 

1 

ZERO, REPLY PTR, OR VALIDATION PTR 
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>18 

! 

+- 

MRBXFL 

+ 

1 

-+ 

>1A 

! 

+- 

MRBFCH 

i 

MRBEVT 

! 

-+ 

>1C 

! 

+- 

MRBCRO 

i 

-+-- 

MRBCCO 

! 

-+ 

>1E 

j 

+- 

MRBFRO 

1 

MRBFCO 

.1 

— + 


EXTENDED REQUEST FLAGS 

VDT FILL CHARACTER 
VDT EVENT BYTE 
VDT CURSOR IN FIELD ROW 

VDT CURSOR IN FIELD COLUMN 
VDT FIELD beginning ROW 

VDT FIELD BEGINNING COLUMN 


WRITE WITH VDT EXTN WITH REPLY 



* - 

+ 



>20 

I 

MRBRS3 

j 

(EXTRA WORD BUFFERED) 


+- 

+ 

— + 


>22 

! 

MRBRY2 

f 

REPLY BUFFER POINTER (OFFSET) 


+- 


— h 


>24 

1 

MRBRI2 

j 

REPLY INPUT COUNT FROM REQUESTOR 


+- 


— + 


>26 

! 

MRBR02 

1 

REPLY OUTPUT COUNT FOR REQUESTOR 


+- 

+ 

— + 





BASI 

C FILE I/O BLOCK 






>16 

I 

MRBRNl 

1 

RECORD NUMBER FOR REL REC (2 WORDS 


+- 


— + 


>18 

! 


j 



+- 


-+ 





KIF 

I/O BLOCK 



+ 



>16 

I 

MRBCBA 

j 

CURRENCY BLOCK ADDRESS 


+- 

+ 

-+ 


>18 

1 

MRBRSO 

t 

RESERVED 


+- 


— + 


>1A 

i 





+- 


-+ 


>1C 

1 

MRBCUR ! 

j 

CURRENCY BLOCK 


+- 


— + 



/ 

/ 

/ 



/ 

/ 

/ 



+- 

+ 

-+ 





I/O 

UTILITY VARIANT 



+ 



>10 

1 

MRBTYP ! MRBTFL 

1 

RESOURCE TYPE 


+- 


-+ 

RESOURCE TYPE FLAGS 

>12 

! 

FILL06 

? 

RESERVED 


+- 

+ 

-+ 


>14 

j 

FILL07 

f 

RESERVED 


+- 


-+ 


>16 

f 

MRBKDB 

f 

KEY INDEX DEFINITION BLOCK (OFFSET 


+- 

+ 

-+ 


>18 

1 

MRBRS4 

r 

RESERVED 
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+ 

-1 

+ 



>1A 

t 

MRBFLG 

1 

UTILITY FLAGS (2 BYTES) 



+ 

+ 




>1C 

1 

MRBDLL 

f 

DEFINED logical RECORD 

LENGTH 


+ 

+ 

+ 



>1E 

I 

MRBDPL 

f 

DEFINED PHYSICAL RECORD 

LENGTH 


+ 

+ 

+ 



>20 

j 

MRBPNA 

1 

PATHNAME ADDR (OFFSET) 



+ 





>22 

! 

MRBPRM 

! 

PARAMETER PTR (OFFSET) 



+ 

+ 

+ 



>24 

1 

MRBRS5 

f 

RESERVED 



+ 

+ 

+ 



>26 

f 

MRBIFA 

f 

INITIAL FILE ALLOCATION 

(2 WORDS) 


+ 

+ 

+ 



>28 

I 


1 




+ 

+ 

+ 



>2A 

I 

MRBSFA 

! 

secondary file ALLOCATION (2 WORDS) 


+ 

+ 




>2C 

I 


! 




+ 

+ 




>30 

SIZE 


** END 

OF PACKED RECORD 



FLAGS FOR FIELD: MRBABF #0C - FLAGS 


MRFDNC - (X 

. . . . ) 

- DO NOT CLOSE 

= ( .XXXXXXX. . . . 

. . . . ) 

- RESERVED 


FLAGS FOR 

FIELD: MRBSFL 

#0E - SYSTEM FLAGS 

MRFBSY = 

(X 

. . . . ) - BUSY 

MRFERR = 

( .X 

. . . . ) — ERROR 

MRFEOF = 

(..X 

. . . . ) - END OF FILE 

MRFVNT = 

(...X 

. . . . ) - EVENT CHAR 


FLAGS FOR FIELD: MRBUFL #0F - REQUESTOR (USER) FLAGS 


MRFINT 

MRFRPY 

MRFRES 

MRFACC 

MRFLOC 

MRFOWN 


(X ) - INITIATE REQUEST 

(.X ) - OUTPUT WITH REPLY 

( . . X ) - RESERVED 

(...XX ) - ACCESS PRIVILEGES 

( X ) - LOCK/UNLOCK 

( XX ) - OWNERSHIP LEVEL 


FLAGS FOR FIELD: MRBDFL /ME - DIOU FLAGS 

MRFLCK = (X ) - LOCK/UNLOCK 

MRFNAM = (.X ) - NAME SPECIFIED 
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MRFVRD = ( . 

. X 

. ...) - VIRTUAL DEVICE 

MRFWCH = (. 


. ...) - WHICH RELATIVE DEVICE 

MRFREP = (. 


. . . . ) - REPLACE 


FLAGS FOR 

FI 

ELD : 

MRBXFL 

#18 

- 

• EXTENDED REQUEST FLAGS 

MRFCSF 

= 

( 

X. . . . 

• •••••• 

) 

— 

CURSOR START OF FIELD DEFN 

MRFNTN 

= 

( 

.X. . . 

• •••••• 

) 

- 

INTENSITY 

MRFFKR 


( 

. .X. . 

• •••••• 

) 

- 

BLINKING CURSOR (FLICKER) 

MRFGRA 

=s 

( 

. . . X. 


) 

- 

GRAPHICS DISPLAY (CHAR LT >20) 

MRFEBA 

= 

( 

• • • • X 

• •••••• 

. . . . ) 

- 

8-BIT ASCII 

MRFTER 

= 

( 

• • « • • 

X . . . . • . 

. . . . ) 

- 

ENABLE TASK EDIT CHAR RETURN 

MRFBP 

= 

( 

• • « • • 

. X . . . . . 

) 

- 

BEEP 

MRFRDB 

= 

( 

• • • • • 

. • X . . • • 

. . . . ) 

- 

RIGHT DISPLAY EDGE BOUNDARY 

MRFCIF 

= 

( 

• • • • • 

• • • X • • • 

) 

- 

CURSOR IN-FIELD DEFINED 

MRFFC 

= 

( 

• • • • • 

• • . . X . . 

) 

- 

FILL CHAR DEFINED 

MRFIF 

= 

( 

• • • • • 

• «... X . 

) 

- 

INITIALIZE FIELD 

MRFRFF 

= 

( 

• • • • • 

• ••••• X 

. . • • ) 

- 

REMAIN IN FULL FIELD 

MRFECO 

= 

( 

• • • • • 

• •••••• 

X. . . ) 

- 

ECHO 

MRFVRQ 

= 

( 

• • • • • 

• •••••• 

.X. . ) 

- 

VALIDATION REQUIRED 

MRFVER 

= 

( 

• # • • • 

• •••••• 

. .X. ) 

- 

VERIFICATION ERROR 

MRFWBP 

z= 

( 

• • • • • 

• •••••• 

. . .X) 


WARNING BEEP 

FLAGS FOR 

FI 

ELD; 

MRBTFL 

#11 

- 

RESOURCE TYPE FLAGS 


= 

( 

XXX. . 


— ) 

— 

RESERVED 

MRFVD 

= 

( 

. . . X. 


— ) 

- 

VIRTUAL DEVICE 

MRFREM 

= 

( 

. . . . X 


— ) 

- 

REMOTE RESOURCE 

MRFCHN 

= 

( 


X 

— ) 

- 

CHANNEL 

MRFDEV 

= 

( 


.X 

— ) 

- 

DEVICE 

MRFFIL 

= 

( 


• • X . . . . 

— ) 

* 

FILE 

FLAGS FOR 

FI 

ELD : 

MRBFLG 

#1A 

. - 

UTILITY FLAGS (2 BYTES) 

MRFFCA 


( 

X. . . . 


. . . . ^ 


FILE CREATED BY ASSIGN 

MRFFUS 

= 

( 

. XX. . 


. . . . ) 

- 

FILE USAGE FLAGS 







00 

=N0 SPECIAL USAGE 







01 

“DIRECTORY FILE 







10 

“PROGRAM FILE 







11 

“IMAGE FILE 

MRFSCP 

= 

( 

. . . XX 


. . . . ) 

- 

LUNO SCOPE 







00 

“TASK LOCAL 







01 

“JOB LOCAL 







10 

“GLOBAL 







11 

“RESERVED 

MRFGEN 

= 

( 


X 

) 

- 

AUTOGENERATE LUNO 

MRFACR 

= 

( 


. X 

) 

- 

REQUEST AUTOCREATE FILE 

MRFPRM 

= 

( 


. . X . . . . 

) 

- 

1“MRBPRM VALID (FARMS PRESENT) 

MRFLRL 

= 

( 


• • • X • • • 

) 

- 

USE logical REC. LENGTH GIVEN 

MRFTMP 

= 

( 


. . . . X . . 

) 

- 

FILE IS TO BE TEMPORARY 
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MRFIMW = ( X ) - IMMEDIATE WRITE DISK'FILES 

MRFDFT = ( XX...) - DATA FORMAT 

* 00=N0RMAL RECORD IMAGE 

* 01=BLANK SUPPRESSED 

* 10,11 RESERVED 

MRFALL = ( X..) “ ALLOCATION MAY GROW 

MRFFTP = ( XX) - FILE TYPE 

* 00=RESERVED 

* 01=SEQUENTIAL FILE 

* 10=RELATIVE RECORD FILE 

* 11=KEY INDEXED FILE 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 

VARNO 

$ 

>0C 


MRBASZ 

$ 

>0E 

ABORT I/O MRB SIZE 

MRFVAL 

MRFRPY 

>01 

READ WITH VALIDATION 

MRFMDS 

MRFLOC 

>05 

MASTER DO NOT SUSPEND 

MRFEXR 

MRFOWN 

>06 

EXTENDED REQUEST 

MRFBAD 

MRFOWN+1 

>07 

BLANK ADJ/SET EVENT MODE 

MRFWPM 

MRFOWN+1 

>07 

WORD PROCESSING MODE 

MRBOSZ 

$ 

>10 


MRBCDE 

MRBUFL 

>0F 

CDE NUMBER WITHIN CDT 

MRBSZD 

$ 

>22 

SIZE OF DIOU VARIANT 

MRBISZ 

$ 

>16 

BASIC I/O MRB SIZE 

MRBDSZ 

$ 

>1A 

DISK I/O MRB SIZE 

MRBRSZ 

$ 

>20 

BASIC REPLY MRB SIZE 

MRBVAL 

MRBROV 

>16 


MRBXSZ 

$ 

>20 

VDT EXTENSION MRB SIZE 

MRBRS2 

$ 

>20 

NO LONGER USED 

MRBVXS 

$ 

>20 

READ WITH EXTN/VALIDATION MRB SIZE 

MRBXRS 

$ 

>28 

WRITE WITH EXTN/REPLY MRB SIZE 

MRBFSZ 

$ 

>1A 

SIZE OF BASIC FILE I/O MRB 

MRBKSZ 

$ 

>30 

SIZE OF KIF MRB 

MRBUSZ 

$ 

>2E 

SIZE OF lOU call block 
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MTX 


icieidfk'kifkifk'kifk'k-k^'k'k-kic'kifkitick'kifk'kit'k'kik'kifk-kifk-kidckifk^'kitickifkidc'k^tic'k 

* 

* EXTENTION FOR A MAGNETIC (MTX) 04/13/83 

* TAPE DEVICE 

* REV 05/10/83 

* LOCATION: SYSTEM AREA 


* 

* 

* 

* 

* 

* 

■k 


* THE MTX IS AN EXTENSION TO THE PDT USED TO DESCRIBE A 

* MAGNETIC TAPE DEVICE. IT IS USED AS A WORK AREA BY 

* THE DSR. 





-+ 

* 





>00 

! 

MTXTIL 

f 

! 

TILINE 

IMAGE 




+- 


-+ 

+ 






/ 


/ 

/ 






/ 


/ 

/ 






+- 


—+—————— 

+ 





>10 

j 

MTXSLG 

1 

! 

TILINE 

IMAGE 

FOR 

SYSTEM LOG 


+- 


—+—————— 

+. 






/ 


/ 

/ 






/ 


/ 

/ 






+- 


—+—————— 

+ 





>20 

1 

MTXSVS 

! 

TILINE 

UNIT 

ERROR 

COUNT 


+- 


-+ 

— — — — + 





>22 

1 

MTXMAJ 

I 

MAJOR 

ERROR 

COUNT 



+- 


_+ 

+ 





>24 

! 

MTXMIN 

I 

MINOR 

ERROR 

COUNT 



+- 


_+ 

+ 





>26 

! 

MTXFLG 

! 

FLAGS 





+- 


-+ 







FLAGS FOR FIELD: MTXFLG 

#26 • 

- FLAGS 


MTFEOT - (X 

...) - 

END-OF-TAPE 

FLAG 

- (.XXX 

...) - 

RESERVED 


MTFODI = (....X 

...) - 

ON-LINE-DIAG 

NOSTICS 

- ( XXXXXXXXXXX) - 

RESERVED 



EQUATES : 




LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


MTXSIZ 

$ 

>28 

MTXCNT 

MTXTIL+> 

>08 

MTXCMD 

MTXTIL+> 

>0C 


MT PDT + EXTENSION SIZE 
BYTE transfer COUNT 
TRANSPORT SELECT/ COMMAND/ADDR 
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* NAME DEFINITION BLOCK (NDB) 

* 


07/16/81 * 

* 


* LOCATION: A NAME DEFINITION SEGMENT * 

*********************************************************** 


* H * 


>00 

! 

NDBNDB 

! 


+- 


-+ 

>02 

I 

NDBPAR 

j 


+- 


— + 

>04 

I 

NDBLLL 

j 


+- 

+ 

-+ 

>06 

j 

NDBRRR 

I 


+- 

+ 

-+ 

>08 

f 

NDBNAM 

J 


+- 

+ 

— + 

>0A 

f 

NDBSVB 

1 


+- 

+ 

— + 

>0C 

1 

NDBBAL ! NDBWAT 

f 


+- 


-+ 


EQUATES : 

LABEL EQUATE TO VALUE 


NDBSIZ $ >0E 


FIXED LINK - SEQ PROCESSING 

POINTER TO PARENT NDB 

POINTER TO LEFT SON 

POINTER TO RIGHT SON 

PTR TO THE NAME 

ANCHOR OF STAGE VALUES 

BALANCE FACTOR 
SON INDICATOR 

DESCRIPTION 
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NDS 


ick-ki{"k-k’kick:ffk'k-k'kifitifkifk-ki(ik4t'k-k4tic‘k-kicitic'ifk‘k'kifkiei(ic'k-kicic’k4fkiciticitifk-kickit^ 
* * 

* NAME DEFINITION SEGMENT OVERHEAD (NDS) 12/16/81 * 

* * 

* LOCATION: A NAME DEFINITION SEGMENT * 




>00 

I 

NDSHED 

j 


+— 


-+ 

>02 

I 

NDSLNK 

f 


+- 


— + 

>04 

1 

NDSRES 

f 


H — 

+ 

— + 

>06 

1 

NDSEND 

1 


+ - 


-+ 

>08 

i 

NDSUSE 

I 


+ - 

+ 

-+ 

>0A 

J 

NDSHI 

f 


+ - 


—+ 

>0C 

j 

NDS JSB 

f 


+ - 


— + 

>0E 

J 

NDSNUL ! NDSOWN 

1 


+- 

+ 

-+ 

>10 

f 

NDSSTR 

f 


+ - 

+ 

-+ 

>12 

J 

NDSLTR 

1 




- + 

>14 

1 

NDSSDB 

j 


+ - 

- 1 - 

— + 

>16 

! 

NDSSYN 

t 


+- 


-+ 

>18 

I 

NDSLGN 

1 


+ — 


— + 

>1A 

I 

NDSTMP 

t 


+- 


— + 


EQUATES : 

LABEL EQUATE TO VALUE 


NDSSIZ $ >1C 


1ST ENTRY ON FREE MEMORY LIST 

PTR TO FREE MEMORY CHAIN 

RESERVED TABLE AREA BOUNDRY 

ACTUAL ADDRESS OF END OF SEG 

CURRENT MEMORY USAGE 

HIGHEST MEMORY ALLOCATION 

PTR TO JSB OR SSB OF OWNER 

HANDY NULL STRING 

SEGMENT IN USE IF NON-ZERO 
PTR TO ROOT OF SYN TREE 

PTR TO ROOT OF LGN TREE 

PTR TO 1ST SDB FOR THE JOB 

FIXED LINK OF SYNONYM NDBS 

FIXED LINK OF NAME NDBS 

TEMPORARY PACKET ADDRESS 

DESCRIPTION 

length of NDS OVERHEAD 
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************************************************************ 
* * 

* SYSTEM CRASH CODE EQUATES (NFCRSH) 06/08/83 * 

* * 

************************************************************ 

* NFCRSH LISTS ALL POSSIBLE SYSTEM CRASH CODES GENERATED BY 

* DNOS. SOME CODES ARE ALSO RESERVED AS THEY ARE USED BY 

* DXIO AND USE OF THOSE BY DNOS WOULD NOT BE DESIRABLE. 


* 

SHOOE EQU >000E 

*CSH010 THRU CSH012 

* CSH013 THRU CSHOIF ILLEGAL 
*CSH020 

* 


CSH021 

EQU 

>0021 

CSH022 

EQU 

>0022 

CSH023 

EQU 

>0023 

CSH024 

EQU 

>0024 

CSH025 

EQU 

>0025 

CSH026 

EQU 

>0026 

CSH027 

EQU 

>0027 

CSH028 

EQU 

>0028 

CSH029 

EQU 

>0029 

CSH02A 

EQU 

>002A 

*CSH02 

B 


CSH02C 

EQU 

>002C 

*CSH02 

a 

D 


*CSH02 

E 


CSH02F 

EQU 

>002F 

CSH030 

EQU 

>0030 


*CSH031 

* 

*CSH032 

* 

*CSH033 

* 

*CSH034 

* 

*CSH035 

* 


*CSH036 

* 


*CSH040 

THRU 

CSH045 

CSH046 

EQU 

>0046 

CSH048 

EQU 

>0048 

CSH04A 

EQU 

>004A 

CSH04B 

EQU 

>004B 

CSH04C 

EQU 

>004C 

CSH04D 

EQU 

>004D 


PMTLDR - CANNOT ASSIGN TO ROLL 
FILE 

RESERVED-USED BY DXIO 
INTERRUPT AT LEVEL 3 THRU F 
RESERVED-DXIO-ILLEGAL INTERNAL 
INTERRUPT 

PMUMGR - INCONSISTENT STRUCTURE 
NFTMGR - INCONSISTENT STRUCTURE 
NFSCHD - queuing ERROR 
lOBM - INCONSISTENT STRUCTURE 
ILLEGAL SYSTEM XOP 
PMROLL - CANNOT EXTEND SWAP FILE 
PMROLL - SWAP FILE WRITE ERROR 
PMLDSG - SWAP FILE READ ERROR 
NFPOP - UNEXPECTED ERROR RETURNED 
NUCLEUS - INCONSISTENT STRUCTURE 
RESERVED-DXIO-ERR IN LDT BUILT 
FOR PROG. FILE 

NFENAB - SCHEDULER INHIBIT NEG . 
RESERVED-DX10-TM$LDR TOOK END 
ACTION 


RESERVED-DX10-SO$CPR 

ERROR 

SYSTEM OVERLAY LOAD 

ERROR 

NFTMGR - NO 

SYSTEM TABLE 

AREA 

RESERVED-DX 

10-UNEXP 

ERR 

RETURN 

IN 

RM$REL 



RESERVED-DX 

10-UNEXP 

ERR 

RETURN 

IN 

BM$TRW 



RESERVED-DX 

10-UNEXP 

ERR 

RETURN 

IN 

BM$W 



RESERVED-DX 

10-UNEXP 

ERR 

RETURN 

IN 

BM$CL0 



RESERVED-DX 

10-UNEXP 

ERR 

RETURN 

IN 

BM$FLS 



RESERVED-DX 

10-UNEXP 

ERR 

RETURN 

IN 

BM$SCH 



RESERVED-DX 

10- 



SEGMGR - INCONSISTENT STRUCTURE 


JOBMGR - END ACTION TAKEN 
JOBMGR - TASK QUEUING ERROR 
JOBMGR ~ ERROR FROM SEG MGR 
JOBMGR - error FROM lOU 
JOBMGR - CANNOT GET TABLE AREA 
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NFCRSH 


*CSH050 



CSH051 

k 

EQU 

>0051 

CSH060 

EQU 

>0060 


-k 

* 

* 

* 

* 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 

k 


RESERVED-DXIO- 
PROGRAM FILE SVC'S - 

INCONSISTENT LDT LIST 
NFINT2 - INTERNAL INTERRUPT 
60 THRU 6F RESERVED FOR 
INTERNAL INTERRUPTS 0 - F 

60 - INVALID INTERNAL INTERRUPT 

61 - MEMORY PARITY 

62 - ILLEGAL INSTRUCTION 

63 - TILINE TIMEOUT 

64 - ILLEGAL SUPERVISOR CALL 
(RESERVED, SOFTWARE DETECTED) 

65 - MAPPING ERROR 

66 - PRIVILEGED OPCODE 

67 - TASK IS BEING KILLED 
(RESERVED, SOFTWARE DETECTED) 

68 - NOT ENOUGH USER TASK AREA 

SOFTWARE DETECTED 

69 - SEGMENT NOT PRESENT 

6A - EXECUTE PROTECT VIOLATION 
6B - WRITE PROTECT VIOLATION 
6C - STACK OVERFLOW 
6D - HARDWARE BREAKPOINT 
6E - 12 MS CLOCK EXPIRED 
6F - arithmetic OVERFLOW 
DISK SPACE 


*CSH070 

THRU 

f CSH076 

RESERVED-DXIO- 

CSH077 

EQU 

>0077 

MEDIA CHANGE OCCURRED ON SYS DISK 

CSH080 

EQU 

>0080 

DSKMGR 

- END ACTION TAKEN 

*CSH081 



RESERVED-DXIO- 

CSH082 

EQU 

>0082 

DSKMGR 

- UNDEFINED OP CODE 

CSH083 

EQU 

>0083 

DSKMGR 

- ADU ALLOCATED ALREADY USED 

CSH084 

EQU 

>0084 

DSKMGR 

- FIRST available ADU 

* 




OUT OF RANGE 

CSH085 

EQU 

>0085 

DSKMGR 

- ILLEGAL PARTIAL BIT MAP 

k 




NUMBER REQUESTED 

CSH086 

EQU 

>0086 

DSKMGR 

- CACHED BIT MAP HAS 

k 




BEEN MODIFIED 

CSH087 

EQU 

>0087 

DSKMGR 

- READ AFTER WRITE OF 

k 



PARTIAL 

BIT MAP DOES NOT VERIFY 

*CSH088 

THRU 

CSH089 

RESERVED-DXIO- 

CSH090 

EQU 

>0090 

INVALID 

USE OF VTOl 

CSH094 

EQU 

>0094 

DSR940 

- CAN'T GET BUFFER TABLE AREA 

CSHOAO 

EQU 

>00A0 

FILMGR 

- END ACTION TAKEN 

CSHOAl 

EQU 

>00A1 

FILMGR 

- ERROR LOADING FM OVERLAY 

CSH0A2 

EQU 

>00A2 

FILMGR- 

INCONSISTENT STRUCTURE 

*CSH0A3 

THRU 

CSH0A4 

RESERVE 

D-DXIO- 

*CSH0AF 



RESERVE 

D-DXIO- 

CSHOBO 

EQU 

>00B0 

NAMMGR 

- END ACTION TAKEN 

CSHOBl 

EQU 

>00B1 

NAMMGR 

- PASCAL RUN-TIME ABORT 

CSH0B2 

EQU 

>00B2 

lOTBID 

- END ACTION TAKEN 

CSH0B3 

EQU 

>00B3 

IPCTSK 

- END ACTION TAKEN 

CSH0B5 

EQU 

>00B5 

PMOVYL 

- END ACTION TAKEN 
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CSH0B6 EQU >00B6 
CSH0B7 EQU >00B7 
CSH0B8 EQU >00B8 
CSH0B9 EQU >00B9 
CSHOBA EQU >00BA 
CSHOBB EQU >OOBB 
CSHOBD EQU >OOBD 
CSHOBE EQU >OOBE 
CSHOCO EQU >OOCO 
*CSHOEO THRU CSHOE5 
CSHIOO EQU >0100 
CSHlOl EQU >0101 
CSH102 EQU >0102 
*CSH103 THRU CSH106 
CSH107 EQU >0107 
*CSH108 THRU CSH109 
CSHIOA EQU >010A 
* 

*CSH10B THRU CSHIOD 
CSHIOE EQU >010E 
*CSH120 THRU CSH123 
*CSH130 THRU CSH131 
CSH132 EQU >0132 
*CSH133 THRU CSH137 
CSH138 EQU >0138 
CSH139 EQU >0139 
CSH13A EQU >013A 
CSH13B EQU >013B 
CSH13C EQU >0130 
CSH13D EQU >013D 
CSH13E EQU >013E 
*CSH1 3F 
*CSH1 40 

SH141 EQU >0141 

CSH142 EQU >0142 
CSH143 EQU >0143 

* 

CSH144 EQU >0144 

* 

CSH145 EQU >0145 
CSH146 EQU >0146 
*CSH1 47 
* 

*CSH1 50 
* 

CSH160 EQU >0160 
CSH161 EQU >0161 
* 

CSH162 EQU >0162 
* 

* 

CSH163 EQU >0163 


PMTBID - END ACTION TAKEN 
PMWRIT - END ACTION TAKEN 
PMTLDR - END ACTION TAKEN 
PMTERM - END ACTION TAKEN 
PMSBUF - END ACTION TAKEN 
PMRWTK - END ACTION TAKEN 
PMSBID - END ACTION TAKEN 
RCP - END ACTION TAKEN 
NFEOBR - TSBIO HAS BECOME NEGATIVE 
RESERVED-DXIO- 
lOU - END ACTION TAKEN 
lOU “ WRONG SEGMENT MAPPED 
lOU - LOOKUP, de-link FAILURE 
RESERVED-DXIO- 
lOU - BAD FILE LDT LIST 
RESERVED-DXIO- 
lOU - ERROR RETURNING ADU 
JUST OBTAINED 
RESERVED-DXIO- 

lOU - FCB BLOCK COUNT OVERFLOW 
RESERVED-DXIO- 
RESERVED-DXIO- 
RPUTIL - END ACTION TAKEN 
RESERVED-DXIO- 
RPIV -BIT MAP TABLE ERROR 
RPINV2 - DISK ALLOCATION FAILURE 
RPINV2 - BAD BIT MAP NUMBER 
RPINV2 - BAD ADU LIST RANGE OVERLAP 
NFPWUP - NO POWER DOWN INTERRUPT 
NFPWUP - CANNOT FIND RTWP CONTEXT 
NFPWUP - INVALID RTWP CONTEXT 
RESERVED-DXIO- 
RESERVED-DXIO- 
RESERVED-DX7 -NO POWER FAIL 
RECOVERY SUPPORT 
UNIV BLD -NO TERMINAL AVAILABLE 
UNIV BLD -I/O ERROR TO TERMINAL 
WHILE BUILDING DISK 
UNIV BLD -NO RESPONSE TO INITIAL 
MESSAGE 

IPC - INCONSISTENT DATA STRUCTURES 
DIOU TOOK END ACTION 
RESERVED-DXIO-PDT' S POINTER TO 
PRB IS INVALID 

RESERVED-DX7 -DISK CHANGED WITH 
NO UNLOAD (UV) COMMAND 
(RESERVED DX10-TM$BID END ACTION) 
lOU (SECMGR) - UNABLE TO OPEN 
LUNO TO .S$CLF 

lOU (SECMGR) - UNABLE TO CREATE 
OR MAP SPECIAL SEGMENT FOR 
BUILDING capability LIST 
RESTART - JUST MADE CRASH FILE 
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NFCRSH 


* BIGGER, SO WE FORCED CRASH 

*CSH177 RESERVED-DXIO- 

**********************;************************************** 


* 


■k 


* SYSTEM LOADER FLASH CRASH CODES 

* 


* 

* 


************************************************************ 


FLSHOl EQU 
FLSH02 EQU 
FLSH03 EQU 
FLSH04 EQU 
FLSH05 EQU 
* 

FLSH06 EQU 
FLSH08 EQU 
FLSH09 EQU 
FLSHOA EQU 
FLSHOB EQU 
FLSHOC EQU 
FLSHOD EQU 
FLSHOE EQU 
FLSHOF EQU 
* 

FLSHll EQU 
FLSH13 EQU 
FLSH14 EQU 
*FLSH60-6F 
FLSH68 EQU 


>0001 

>0002 

>0003 

>0004 

>0005 

>0006 

>0008 

>0009 

>000A 

>000B 

>000C 

>000D 

CSHOOE 

>000F 

>0011 

>0013 

>0014 

EQU >60->6F 
>0068 


LOAD DEVICE I/O ERROR 
NOT ENOUGH PHYSICAL MEMORY 
CAN'T FIND SYSTEM DISK PDT 
ERROR IN PROG FILE DIRECTORY 
S$IPL INCONSISTENT WITH REV. 

LEVEL OF CURRENT SYSTEM 
ERROR IN DM BIT MAP ROUTINE 
CAN'T FIND SYSTEM LOADER FILE 
CAN'T FIND KERNEL PROGRAM FILE 
CAN'T FIND A SYSTEM SEGMENT 
NO PATCHES APPLIED TO SYSTEM 
SOFTWARE VERSION TOO OLD 
CAN'T FIND UTILITIES PROG FILE 
CAN'T FIND SYSTEM ROLL FILE 
KERNEL FILE LEVEL INCONSISTENT 
WITH UTILITY FILE 
CAN'T GET SYSTEM TABLE AREA 
LOGICAL ADDRESS OVERFLOW 
CAN'T LOAD WCS FILE 
INTERNAL INTERRUPT (LEVEL 2) 
not enough user task AREA 
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TASK STATE CODES 


(NFSTAT) 


09/20/83 


NOTES : 

1 ) 


THIS MODULE REQUIRES NFEROO THRU NFER40 BE 
COPIED ALSO. 


* 2) CHANGES TO THIS MODULE REQUIRE CORRESPONDING * 

* CHANGES IN 3 OF THE MESSAGES IN THE SVC MESSAGES * 

* FILE. (SVC >35, SVC >07, AND SVC OE) * 

************************************************************ 

* THESE EQUATES DESCRIBE ALL THE LEGAL TASK STATE CODES AND 

* JOB STATE CODES USED BY THE OS. 


TSTACT 

TSTWOM 

TSTJWT 

TSTLIP 

TSTTRM 

TSTDLY 

TSTSUS 

TSTENX 

* 

TSTSIO 

TSTSAI 

TSTOVL 

TSTCOA 

TSTWIO 

TSTDOR 

TSTSBT 

TSTIV 

TSTDMG 

TSTQIN 

TSTIT 

TSTIP 

TSTIO 

TSTDT 

TSTDP 

TSTDO 

TSTBID 

TSTRWT 

TSTWOT 

TSTMNI 

TSTUV 

TSTAIO 

TSTAPS 

TSTINV 

TSTSEM 

TSTSEG 

TSTEWT 

TSTNMG 

TSTJMR 


BYTEOO 

BYTEOl 

BYTE02 

BYTE03 

BYTE04 

BYTE05 

BYTE06 

BYTE07 

BYTE09 
BYTEOF 
BYTE 14 
BYTEl 7 
BYTE19 
BYTEIE 
BYTEl F 
BYTE20 
BYTE22 
BYTE24 
BYTE25 
BYTE26 
BYTE27 
BYTE28 
BYTE29 
BYTE2A 
BYTE2B 
BYTE2D 
BYTE30 
BYTE31 
BYTE34 
BYTE36 
BYTE37 
BYTE38 
BYTE3D 
BYTE40 
BYTE42 
BYTE43 
BYTE48 


TASK IS ON ACTIVE LIST 

TASK IS WAITING ON MEMORY 

JOB IN A NONEXECUTABLE STATE 

TASK LOAD IN PROGRESS 

TASK HAS TERMINATED 

TASK IS IN A TIME DELAY 

TASK UNCONDITIONALLY SUSPENDED 

WAITING FOR TEN X PROCESSOR 

COMPLETION 

TASK SUSPENDED FOR I/O 
SUSPENDING FOR ABORTING I/O 
WAITING FOR OVERLAY LOAD SVC 
TASK AWAITING COROUTINE ACT 
WAITING FOR INITIATED I/O 
WAITING FOR DOOR TO OPEN 
WAITING FOR SCHD TASK BID SVC 
WAITING FOR INSTALL VOLUME SVC 
WAITING FOR DISK MGR SVC 
AWAITING QUEUE INPUT 
WAITING FOR INSTALL TASK SVC 


WAITING FOR INSTALL TASK SVC 
WAITING FOR INSTALL PROC SVC 
WAITING FOR INSTALL OVLY SVC 
WAITING FOR DELETE TASK SVC 
WAITING FOR DELETE PROC SVC 
WAITING FOR DELETE OVLY SVC 
TASK SUSPENDED FOR BID SVC 
WAITING FOR READ/WRITE TSK SVC 
WAITING FOR SYSTEM TABLE AREA 
WAITING FOR MAP PROG NAME TO ID 
WAITING FOR UNLOAD VOLUME SVC 
WAITING FOR ANY I/O 
WAITING FOR ASG PROG FILE SPACE 
WAITING FOR INIT NEW VOL SVC 
TASK SUSPENDED FOR SEMAPHORE 
TASK AWAITING SEG MGR SERVICES 
WAITING FOR EVENT COMPLETION 
WAITING FOR NAME MGR SVC 
TASK WAITING ON JOB MGR SVC 


WAITING 

WAITING 

WAITING 

WAITING 

WAITING 

WAITING 
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TSTFRL EQU BYTE4A WAITING FOR FORCED ROLL SVC 

TSTRCP EQU BYTE4C WAITING FOR RETURN CODE PROC 

* * 


* JOB STATE CODES * 

* * 


************************************************************ 


JSTCRE EQU BYTEOl JOB IS BEING CREATED 

JSTEXC EQU BYTE02 JOB IS IN A EXECUTABLE STATE 

JSTHLT EQU BYTE03 JOB IS HALTED 

JSTTRM EQU BYTE04 JOB IS TERMINATING 

JSTEXP EQU BYTE05 JCA IS BEING EXPANDED 
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A 

* NAME REQUEST BLOCK (NRB 

* 

* LOCATION: SYSTEM TABLE 


****************************** 

* 

) 09/09/83 * 

* 

AREA * 

****************************** 


NAME MGR REQUEST BLOCK 


* 


>00 

j 

NRBSOC 

NRBEC 

1 


+- 

+ 

-+ 

>02 

f 

NRBOC 

NRBFLG 

J 


+- 

+ 

-+ 

>04 

j 

NRBNAM 

f 


+- 


-+ 

>06 

t 

NRBVAL 

j 


+- 

+ 

-+ 

>08 

I 

NRBPRM 

I 


+- 

+ 

— + 


SVC CODE 

ERROR CODE 
SUBOPCODE 

USER SET flags 

PTR TO "NAME" (OR NAME LIST) 
PTR TO "VALUE" OR PATHNAME 
PTR TO "PARMS" LIST 


* — — — -l — * 


>0A 

f 

NRBPNO 

f 


+- 

+ 

-+ 

>0C 

I 

NRBRS V 

t 


+- 

+ 

-+ 

>0E 

i 

NRBTSK 

NRBSTG 

f 


+- 

-h 

-+ 

>10 

1 

NRBSMT 

j 


+- 

+ 

- + 

>12 

I 

NRBSSB 

f 


+- 


-+ 

>14 

1 

NRBVBL 

NRBPBL 

I 


+- 


- + 

>16 

1 

NRBLNA 

1 


+- 

+ 


>18 

I 

NRBLVA 

j 


+- 


“ + 

>1A 

1 

NRBLPA 

f 


+- 

+ 

-+ 


PATHNAME NUMBER 

RESERVED 

TASK ID 

STAGE NUMBER 
SMT FOR NAME SEGMENT 

SSB FOR NAME SEGMENT 

VALUE BUFFER LENGTH 

farms BUFFER LENGTH 
NAME POINTER -LOGICAL ADDRESS 

VALUE pointer-logical ADDRESS 

PARMS POINTER-LOGICAL ADDRESS 


* -t- * 

>0A ! NRBSSZ ! SEGMENT SIZE 

+ -H + 


* -f * 

>0A ! NRBSPF ! SUCCE S SOR/ PR EDE CE S SOR FLAG 

H — — h — — — — — — — — -|- 
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NRB 


FLAGS FOR FIELD: NRBFLG #03 ■ 

NRFLOG = (X ) - 

NRFINT = (.X ) - 

NRFBID = ( . . X . . ) - 

NRFGLO = ( . . .X ) - 

NRFRID = ( . . . . X ) - 

NRFNMX = ( X ) - 

NRFPRO = ( X ) - 

NRF007 » ( X ) - 

EQUATES : 

LABEL EQUATE TO VALUE 


NRBVAR $ >0A 
NRBSID $ >0C 
NRBSIZ $ >1C 


USER SET FLAGS 

LOG = 1, ELSE SYN OPERATION 
INITIAL TASK IN JOB IF TRUE 
BID = 1, TERMINATION = 0 
GLOBAL REQUEST = 1 

RUN ID SPECIFIED = 1 
NAME SEGMENT CANNOT EXPAND 
PROTECT NAME 
FLAG BIT 7 UNUSED 


DESCRIPTION 


SEGMENT ID 

SIZE OF BASIC BLOCK TO BUFFER 
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* * 

* OVERLAY AREA DESCRIPTOR (OAD) 12101119 * 

* * 

* LOCATION; WITH SYSTEM OVERLAY AREAS * 

*****************************************************tfc****** 

* THE OAD PRECEDES A SYSTEM OVERLAY AND DESCRIBES ITS SIZE 

* AND LOCATION. 


>FFF0 

* 

! 

OADSMT 

SIZE 
* 

I 

OF OVERLAY DESCRIPTOR 

SMT ADDRESS OF OVERLAY 

AREA SEGMENT 

>FFF2 

I 

OADSSB 

+ 

1 

SSB ADDRESS OF 

OVERLAY 

AREA SEGMENT 

>FFF4 

+ 

j 

OADOFF 

+ 

1 

OFFSET INTO SEGMENT OF 

OVERLAY CODE 

>FFF6 

! 

OADBSZ 

+ 

1 

NUMBER OF BYTES 

TO READ 


>FFF8 

1 

OADSIZ 

1 

SIZE OF OVERLAY 

AREA 


>FFFA 

+ 

1 

OADOVN 

+ 

j 

CURRENT OVERLAY 

IN AREA 

-1=N0NE 

>FFFC 

+ 

! 

OADUSE 

1 

NUMBER OF TASKS 

USING THE OVERLAY 

>FFFE 

+ 

} 

OADOAD 

! 

POINTER TO NEXT 

OVERLAY 

AREA 

+ 

EQUATES : 

LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 



OADSZ 

$ 

>FFFO SIZE OF OVERLAY DESCRIPTOR 
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OAW 


** 

* 

* 

* 

* 

* * 


* 

OVERLAY AREA WAIT BLOCK (OAW) 11/08/79 * 

* 

LOCATION; SYSTEM TABLE AREA * 

**********************************:*:*********************** 


* 

* 

■k 

k 

k 


THE OAW IS USED TO REPRESENT THE TASK WAITING FOR ONE 
SYSTEM OVERLAY OF A POOL OF OVERLAYS. THE POOL MANAGER 
MAINTAINS A LIST OF OAW ENTRIES AND WHEN AN OVERLAY IS 
FREE, CHECKS TO SEE IF ANY TASK IS WAITING FOR IT. IF SO, 


THE 

OVERLAY 

IS LOADED 

AND TH 

TASK IS 

ACTIVATED . 


* — 

+ 




>00 

f 

OAWOAW 

! 

NEXT WAIT BLOCK 


+ 

+ 

+ 



>02 

f 

OAWJSB 

1 

JSB OF 

WAITING TASK 


+ 


+ 



>04 

1 

OAWTSB 

1 

TSB OF 

WAITING TASK 



+ 

+ 



>06 

f 

OAWOVN 

f 

NUMBER 

OF OV AREA BEING WAITED 


+ 

+ 

+ 




FOR 


EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


OAWSIZ 


>08 
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* 

* OWNED SEGMENT ENTRY (OSE) 09/23/81 

* 

* LOCATION: JCA 

*********************************************************** 

* THE OSE DESCRIBES A SEGMENT WHICH IS EXCLUSIVELY USED BY 

* TASK. IT IS LINKED TO THE TSB. 


* H * 


>00 ! 

OSEOSE 

f 

link to next owned segment entry 

+ 

>02 ! 

OSESSB 

+ 

I 

SSB ADDRESS OF 

OWNED SEGMENT 

+ 

>04 ! 

OSESMT 

. — — — + 

! 

SSB ADDRESS OF 

SEGMGR TABLE AREA 

+ 

+ 

+ 



EQUATES : 

LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


OSESIZ 

$ 

>06 




* 

* 

* 

* 

* 

* 

A 
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OTI 


*********************************************************** 


* * 

* OPENING TASK IDENTIFIER (OTI) 08/25/81 * 

* * 

* LOCATION: JCA OR STA * 

*********************************************************** 

* THE OTI IS AN ELEMENT OF A SINGLY LINKED LIST CONTAINING 

* TSB ADDRESSES OF TASKS WHICH HAVE OPENED THE LUNO 

* ASSOCIATED WITH THE PARENT LDT . 


* + * 


>00 ! 

OTIOTI 

t 

-1- 



>02 ! 

OTITSB 

I 

H 

+ 

+ 


link to NEXT OTI 

TSB ADDRESS OF OPENING TASK 


EQUATES ; 
LABEL 
OTISIZ 


EQUATE TO 


$-OTIOTI 


VALUE DESCRIPTION 


>04 SIZE OF OTI 
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*************************************:fc**** -A ***************** 
* * 

* OVERHEAD BEET (OVB) 10/04/83 * 

* * 

* LOCATION: USER MEMORY * 

**************************************************** * * * * * * * * 

* THE OVB IS THE 32 BYTES PRECEDING A SEGMENT WHEN IT IS IN 

* MEMORY. THE OVB INCLUDES LINKAGE, TYPE, AND STATUS 

* INFORMATION ABOUT THE SEGMENT. 

* 

* THE OVFROL FLAG ALSO HAS THE MEANING "SEGMENT LOGICALLY 

* NOT IN MEMORY" . 

* THE OVBTIM IS THE COUNT OF TASKS WHICH BOTH: 

* A) HAVE THE SEGMENT MAPPED IN OR LOADED, AND 

* B) HAVE ALL THEIR MAPPED OR LOADED SEGMENTS PHYSICALLY 

* IN MEMORY. 

* AN OVERRUN BEET IS ALLOCATED AT THE END OF THE SEGMENT 

* TO PREVENT PROBLEMS WHICH COULD OCCUR BECAUSE OF /12 CPU 

* PRE-FETCH OR CACHE FLUSH. 

* 


>00 

*- 

f 

+ 

OVBLEN 

-* 

I 

•_-i- 

LENGTH OF SEGMENT + OVERH^EAD BEET 

-1_ rvTTT? D TJ TTM 'D'C''E’'T’ /■D•C>I7'^0^ 

>02 

f 

OVBPTR 

j 

V i>i Lx Lx U Li xj Lj Lj X y L/ L J Xi X o j 

TSB ADDRESS WHEN BLOCK IS ON TOL 

>04 

*T — 

1 

OVBFLK 

*"r 

I 

..4. 

Lu L ADUKi!iOl> ir DurrliK biljbMr.Ni 

FORWARD LINK TO NEXT BLOCK 

>06 

! 

OVBBLK 

f 

BACKWARD LINK TO NEXT BLOCK 

>08 

f 

OVBTYP ! OVBIOC 

f 

SEGMENT TYPE 

TiTITMI? AMn Oil T / r\ /^ITT'OT'AMtATMr' 

>0A 


OVBJSB 

f 

mmM. 

llLillNEj AIMJJ yil 1/U UUloiAiMUiJNti 

JSB POINTER CORRESPONDING TO OVBPTR 

>0C 

} 

OVBSSB 

j 

SEGMENT STATUS BLOCK POINTER 

>0E 

j 

OVBSMT 

J. 

I 

TABLE AREA SSB ADDRESS 

>10 

! 

OVBQLK 

“"T 

J 

QUEUE LINK ( DEALLOCATE/ WR ITE Q) 

>12 

i 

OVBBRB 

! 

POINTER TO FORCE WRITE BRB 

>14 

I 

FILLOO ! 

I 

RESERVED 

>16 

j 

OVBSTS ! FILLOl 

? 

SEGMENT STATUS (IN MEMORY STATUS) 

>18 

j 

OVBEXC 

1 

Kill D Ej K V iL IJ 

EXECUTION TIME SINCE LOAD 

>1A 

f 

FILL03 ! 

f 

RESERVED FOR FUTURE USE 


H — — — — — — 


>1C ! 
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OVB 


H — — — 1-_ — — — — -f- 

>1E ! OVBTIM { TASK IN MEMORY COUNT 

+ + + 


FLAGS FOR FIELD: OVBSTS #16 - SEGMENT STATUS (IN MEMORY STATUS) 

OVFWRT = (X, ) - SEGMENT ON WRITE QUEUE 

OVFROL = (.X.. ) - FORCE ROLL THIS SEGMENT 

OVFUBS = (..X...... ) - USER SEG USED AS FILE BUFFER 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 

OVSHDR 

>FF 

>FF 

LIST HEADER = -1 

OVSDAT 

>00 

>00 

DATA FILE SEGMENT = 0 

OVSPRO 

>01 

>01 

PROGRAM FILE SEGMENT = 1 

OVSMEM 

>0 2 

>02 

MEMORY BASED SEGMENT = 2 

OVSFRE 

>03 

>03 

FREE BLOCK = 3 

OVSDEL 

>04 

>04 

DEALLOCATE QUEUE SEGMENT 

OVBSIZ 

$ 

>20 
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* * *****************************************jV********5fc******* 

* * 

* OVERLAY TABLE ENTRY (OVT) 05/10/79 * 

* * 

* LOCATION: IN RPSDAT * 

************************************************************ 

* THE SYSTEM OVERLAY TABLE (SOV) CONSISTS OF A NUMBER OF 

* OVERLAY TABLE ENTRIES (OVT). IT IS BUILT DURING SYSTEM 

* GENERATION, BASED ON THE CHOICES REQUESTED THEN. 


— — . — . — * 


>00 

f 

OVTREC 

1 

RECORD 

NUMBER OF OVERLAY 

IMAGE 

>02 

} 

+ 

OVTSIZ 

I 

SIZE OF 

OVERLAY CODE 


>04 

f 

+ 

OVTLOD 

1 

NATURAL 

LOAD ADDRESS OF 

OVERLAY 
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PBM 


************************************************************ 


* * 

* PARTIAL BIT MAP (PBM) 03/06/80 * 

* * 

* LOCATION: DISK, PARTIAL BIT MAP TABLE * 


************************************************************ 

* THE PBM DESCRIBES THE CURRENT ALLOCATION OF A DISK. THE 

* IN-MEMORY PBM IS IN THE PARTIAL BIT MAP TABLE SET ASIDE 

* FOR ONLY PBM TABLES. EACH TIME A FILE IS CREATED OR 

* EXTENDED, THE PBM ISUPDATED IN BOTH MEMORY AND DISK 

* REPRESENTATIONS. 


* 1 * 


>00 

1 

PBMMAX 

j 

PBMNUM ! 

NUMBER OF PARTIAL MAPS 


+- 


• — + — — 

+ 

PARTIAL MAP NUMBER IN BUFFER 

>02 

1 

PBMFAU 

j 

FIRST AVAILABLE ADU ON DISK 


+- 

— 

-- + — 

+ 


>04 

1 

PBMLRC 

1 

LRC CHECKSUM OF MEMORY PBM 


+- 


•— + — — 

+ 


>06 

I 

PBMLCB 

1 

ADU OF LARGEST CONTIGUOUS BLK 


+- 

— 


+ 


>08 

i 

PBMMAP 

f 

f 

PARTIAL BIT MAP 


+- 



+ 



/ 


/ 

/ 



/ 


/ 

/ 



+- 





THIS 

SECTION 

MAPS 

EACH PBM; 

THE DISK MANAGER CAN EXAMINE 


* THIS "MAP" TO DETERMINE ON A FIRST-FIT BASIS THE PARTIAL 

* BIT MAP FROM WHICH TO ALLOCATE WITHOUT SEQUENTIALLY 

* SEARCHING THE DISK- RESIDENT BIT MAPS. THE FOLLOWING 

* STRUCTURE IS REPEATED AS REQUIRED FOR EACH PARTIAL BIT MAP: 

* 



* 

+ 

* 



>00 

I 

PBMBIG 

j 

LARGEST CONTIGUOUS BLK IN PBM 


+ 

+ 

+ 



>02 

1 

PBMBGN 

f 

CONTIGUOUS 

BLK AT START 


+ 

+ 

— “ — — *1" 



>04 

I 

PBMEND 

! 

CONTIGUOUS 

BLK AT END 


+ 

+ 

— *1“ 




EQUATES : 

LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 



PBMBLK 

256 

>100 

PARTIAL 

BIT MAP 

BLOCK SIZE 

PBMLEN 

PBMBLK/ 2 

>7F0 

ADU'S IN 

PARTIAL 

BIT MAP 

PBMTAB 

$ 

>106 

START OF 

BIT MAP 

TABLE 
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PBMSIZ 

$ 

>106 

PBM 

BUFFER/TABLE SIZE 

PBMTES 

$ 

>06 

SIZE 

OF EACH TABLE ENTRY 
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PDT 


************ * * ********************************************** 


* 


* 


* PHYSICAL DEVICE TABLE (PDT) 

* 


06/22/83 * 
* 


* LOCATION: SYSTEM AREA * 

************************************************************ 

* EACH DEVICE GENERATED INTO A SYSTEM IS REPRESENTED BY A 

* PDT. THE PDT IS USED AS A WORK AREA FOR THE DEVICE SERVICE 

* ROUTINE WHILE PROCESSING REQUESTS FOR THE PARTICULAR DEVICE. 
************************************************************* 


* -I * 


>00 

I 

PDTPDT 

f 

— 4- 

>02 

f 

PDTNAM ! 

f 

>04 

1 

! 

t 

>06 

•r — 

I 

PDTNUM 

f 

>08 

T* 

i 

PDTLC ! PDTIL 

! 

>0A 

f 

PDTCHR ! PDTCDT 

! 

>0C 

! 

PDTCDE 

! 

>0E 

! 

PDTFLG 

I 

>10 

I 

PDTMAP 

! 


•T** 

/ 

/ 

/ 

/ 

/ 

/ 

— 4. 

>1C 

1 

PDTJOB 

! 

>1E 

•T^ 

1 

PDTRPB 

f 

.4. 

>20 

! 

PDTBQ 

f 

— 4* 

>22 

•r“ 

! 

PDTRO 

I 

•«4- 

>24 

T"'* 

f 

PDTPRB 

1 

•»4- 

>26 

•r*" 

I 

PDTDSF 

I 

*•4- 

>28 

T" — 

! 

PDTDTF ! PDTTYP 

j 

.»4- 

>2A 

I 

PDTDIB 

1 

— 4- 

>2C 

T — 

I 

+ - 

PDTR5 

+ 

I 

■" + 


FORWARD LINKAGE TO NEXT PDT 
DEVICE NAME 

DEVICE NUMBER 

LUNOS ASSIGNED COUNT 

INITIATE REQUEST LIMIT 
BID CHARACTER 
CDT NUMBER 
DEVICE CDE MASK 

DEVICE STATUS FLAGS EXTENSION 

DSR MAP FILE 

JSB ADDRESS OWNER JOB 

RESOURCE PRIVILEGE BLOCK POINTER 

BID REQUEST QUEUE 

RO - DSR SCRATCH 

R1 - QUEUED PRB ADDRESS 

R2 - DEVICE STATUS FLAGS 

R3 - DEVICE TYPE FLAGS 
- DEVICE TYPE 

R4 - DEVICE INFO BLOCK ADDRESS 
R5 - DSR SCRATCH 
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PDT 


>2E 

I 

PDTR6 

1 


+- 


- + 

>30 

I 

PDTR7 

I 


+- 

+ 

-+ 

>32 

1 

PDTR8 

J 


+- 


-+ 

>34 

1 

PDTR9 

1 


+- 


-+ 

>36 

! 

PDTRIO 

! 


+- 


-+ 

>38 

j 

PDTRl 1 

j 


+- 

+ 

-+ 

>3A 

f 

PDTCRU 

1 


+- 

+ 

— + 

>3C 

1 

PDTR13 

I 


+- 

+ 

-+ 

>3E 

1 

PDTR14 

j 


+- 

+ 

-+ 

>40 

1 

PDTRl 5 

j 


+— 


— + 

>42 

I 

PDTERR ! PDTRTY 

1 


+- 

+ 

-+ 

>44 

I 

PDTRC 

1 


+- 

+ 

-+ 

>46 

f 

PDTWC 

1 


+- 

+ 

“+ 

>48 

! 

PDTMC 

1 


+- 


-+ 

>4A 

! 

PDTREC 

! 


+- 

+ 

-+ 

>4C 

I 

PDTWEC 

1 


+- 

+ 

-+ 

>4E 

I 

PDTMEC 

j 


+- 


-+ 

>50 

1 

PDTSLl 

1 


+- 


-+ 

>52 

I 

PDTSL2 

! 


+- 


— + 

>54 

j 

PDTBLN 

1 


+- 


- + 

>56 

? 

PDTTMl 

I 


+- 


- + 

>58 

I 

PDTTM2 

! 


+- 

+ 

- + 

>5A 

J 

PDTHRQ 

1 


+- 

+ 

- + 

>5C 

! 

PDTWQ 

j 


+ — 


— + 

>5E 

1 

PDTSRB 

1 


+- 


- + 

>60 

f 

PDTERQ 

! 


+- 

+ 

- + 

>62 

I 

PDTSRQ 

f 
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R6 

— 

DSR 

SCRATCH 

R7 

- 

DSR 

SCRATCH 

R8 

- 

DSR 

SCRATCH 

R9 

- 

DSR 

SCRATCH 

RIO 

- 

DSR 

SCRATCH 

R1 1 

- 

DSR 

SCRATCH 

R12 

- 

CRU 

OR TILINE ADDRESS 

R13 

- 

SAVED WP 

R14 

- 

SAVED PC 

R15 

- 

SAVED ST 

SAVED 

ERROR CODE FOR SYS LOG 


RETRIES ATTEMPTED COUNT 
READ REQUEST COUNT 

WRITE REQUEST COUNT 

MI SC REQUEST COUNT 

READ ERROR COUNT 

WRITE ERROR COUNT 

MI SC ERROR COUNT 

SYSTEM LOG INFO 

SYSTEM LOG INFO 

MAXIMUM BUFFER LENGTH 


TIME 

OUT 

COUNT 


TIME 

OUT 

COUNT 

DOWN 

hidden request 

QUEUE 


WAITING REQUEST QUEUE 
SAVED REQUEST ADDRESS 
END -OF-RECORD QUEUE 
SPENT REQUEST QUEUE 
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PDT 


+ + + 

>64 ! PDTPDS ! PRIORITY DSR SCHEDULER QUE LINK 

+ + + 


FLAGS FOR FIELD: PDTFLG 


#0E DEVICE STATUS FLAGS 


EXTENSION 


* 

* 


DFGIRB = (X ) 

= (.XX ) 

PDFSTA = ( . . . XX ) 


DFGOPF = ( 
= ( 

DFGVRT = ( 
= ( 


X ) 

•X ) 

• - X ) 

. . . XXXXXXXX) 


COPY IRB TO SYSTEM LOG 

RESERVED 

DEVICE STATE 

00 ONLINE 01 offline 

10 DIAGNOSTIC 11 SPOOLER 
DEVICE OPERATION FAILED 
RESERVED 

VIRTUAL DEVICE FLAG 

NIO-KEYBOARD BID OWNER TASK RUN ID 


FLAGS FOR FIELD: PDTDSF #26 - R2 - DEVICE STATUS FLAGS 


DSFCMO 

DSFAID 

DSFBI 

DSFBO 

DSFJIS 

DSFREN 

DSFJAR 

DSF JAT 

DSFWPM 

DSFIRE 

DSFINT 


= (X ) 

= ( .X ) 

= (..X ) 

= (...X ) 

= ( X ) 

= (. X ) 

= ( X ) 

= ( X ) 

= ( XX ) 

= ( X ) 

= ( X ) 

= ( XXXX) 


OPENED WITH COMM OPEN (>4E) 
USE ALTERNATE PDT 
BUFFER INPUT (1=YES) 

BUFFER OUTPUT (1=YES) 

JISCII FLAG(KATAKANA) 

RE-ENTER-ME 

JISCII RECEIVE MODE 

JISCII TRANSMIT MODE 

RESERVED 

WORD PROCESSING MODE 
INITIAL REQUEST ENTRY 
DEVICE INTERRUPT LEVEL MASK 


FLAGS FOR FIELD: PDTDTF #28 - R3 - DEVICE TYPE FLAGS 


DTFFIL = (X ) 

DTFTIL = (.X ) 

DTFTIM = ( . . X ) 

DTFPRI = (...X ) 

DTFKSB = ( . . . . X ) 

DTFCOM = ( X ) 

DTFSYD = ( X ) 

= ( X ) 


FILE ORIENTED 
TILINE DEVICE 
ENABLE TIME-OUT 
PRIVILEDGED DEVICE 
TERMINAL WITH A KSB 
COMM DEVICE 
SYSTEM DISC 
RESERVED 


EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


PDFDSM >1800 
PDTOCN PDTMAP 
PDTRDN PDTR5 


>1800 DEVICE STATE MASK 

>10 VIRT PDTS ONLY-OWNER CHANNEL LEN/NA 
>2C VIRT PDTS ONLY-REMOTE DEVICE LEN/NA 
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PDTRDJ PDTCRU >3A VIRT PDTS ONLY-REMOTE DEVICE JOB ID 

PDTSIZ $ >66 


Structure Pictures 
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******************:*?*:%*************************************** 

* * 

* PROGRAM FILE DIRECTORY INDEX ENTRY (PFI) 04/20/79 * 

* * 

* LOCATION; DISK . * 

icit'kickifk-kicitidck^'ick'kickie'kifk'k'kick'kitickieickic'kidcieififkifkifk'/tic'kicitit^ie'k’kiciticit 

* THE PFI IS USED TO DESCRIBE AN ENTRY IN A PROGRAM FILE. 

* ENTRIES CAN BE TASK SEGMENTS, PROCEDURE SEGMENTS, PROGRAM 

* SEGMENTS, AND OVERLAYS, IN ADDITION TO A COMMON FIRST 

* PORTION, THERE IS A SEPARATE VARIANT FOR EACH TYPE OF 

* ENTRY. IN THE FLAG COMMENTS, T INDICATES THE COMMENT APPLIES 

* TO A TASK ENTRY, P TO A PROCEDURE ENTRY, S TO A PROGRAM 

* SEGMENT ENTRY AND 0 TO AN OVERLAY ENTRY. 


>00 

! 

PFILEN 

f 

SEGMENT LENGTH (BYTES) 

>02 

f 

PFIFLG 

j 

FLAGS 

>04 

I 

PFIREC 

! 

RECORD NUMBER OF START OF IMAGE 

>06 

1 

PFIDAT 

j 

DATE installed IN JULIAN FORMAT 

>08 

j 

PFILOD 

! 

LOAD ADDRESS IN TASK 


+ + + 


TYPE DEPENDENT DATA (ANY SET) 

* 

! SINGLE PORTION OF DATA 

+ 

I 

+ 

I 

+ 

TASK ENTRY DESCRIPTION 
* 

I overlay link 

+ TASK priority 

! ID OF PROCEDURE 1 FOR TASK 
+ ID OF procedure 2 FOR TASK 

! TASK LENGTH 

+ 


OVERLAY ENTRY DESCRIPTION 

* 1 * 

>0A ! PFIOV2 ! PFITID ! OVERLAY LINK 

+ + + jD OF associated TASK 

>0C ! PFIOND ! RESERVED (SET TO ZERO) 

+ + + 


* 

>0A ! 
+ 

>0C ! 
+ 

>0E ! 
+ 


>0A 

* - 

I 

PFIOVL 

_+ — 

J 

PFIPRI 

>0C 

+- 

1 

PFI SGI 

-+ — 

I 

PFISG2 

>0E 

+- 

J 

+- 

+ — 

PFITND 



+ 

PFIVAR ! 

— + 

I 

+ 

j 

+ 
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PROCEDURE/PROGRAM ENTRY DESCRIPTION 

it — — — 

>0A ! PFIPND 1 RESERVED (SET TO ZERO) 

+ + + 

FLAGS FOR FIELD: PFIFLG //02 - FLAGS 

PFFPRI = (X ) - PRIVILEGED (T) 

PFFSYS = (.X ) - SYSTEM (T,S) 

PFFRES = (..X ) - MEMORY RESIDENT (T,P,S) 

PFFDEL = (...X ) - DELETE PROTE CTED ( T , P , S , 0 ) 

PFFREP = (....X ) - REPLICATABLE (T,S) 

PFFSGl = ( X ) - PROC 1 IS ON THE PROG FILE (T) 

PFFSG2 = ( X ) - PROC 2 IS ON THE PROG FILE (T) 

PFFUSE = ( X ) - PFI ENTRY IS IN USE (T,P,S,0) 

PFFOVF = ( X ) - OVERFLOW (T) 

PFFWCS = ( X ) - WRITEABLE CONTROL STORE (T,P,S) 

PFFEXP = ( X ) - EXECUTE PROTECTED (T,P,S) 

PFFWRP = ( X....) - WRITE PROTECTED (P,S) 

PFFUPD = ( X...) - UPDATABLE (T,S) 

PFFREU = ( X..) - REUSABLE (T,S) 

PFFCPY = ( X.) - COPYABLE (T,S) 

PFFSEC - ( X) - SECURITY BYPASS (T) 

* 


EQUATES ; 


LABEL 

EQUATE TO 

VALUE 

PFFRED 

PFFPRI 

>00 

PFFSHR 

PFFSGl 

>05 

PFFSPR 

PFFWRP 

>0B 

PFISIZ 

$ 

>10 


DESCRIPTION 


READABLE (P) 

SEG. IS SHARE PROTECTED (S) 
software privileged (T) 


Structure Pictures 
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PFZ 


* * 

* PROGRAM FILE RECORD ZERO (PFZ) 3 / 7/78 * 

* * 

* LOCATION: DISK * 

************************************************************ 

* THE PFZ DESCRIBES THE FIRST RECORD (RECORD 0) OF THE 

* PROGRAM FILE. IT INCLUDES BIT MAPS FOR ALL ELEMENTS IN 

* THE PROGRAM FILE AS WELL AS DATA ABOUT CURRENT USE OF 

*"the file. 


>00 


>14 


*. 

j 

+- 

/ 

/ 

+■ 

j 

+■ 

/ 

/ 


PFZRES 


PFZMRT 


I 

■+■ 

/ 

/ 

•+■ 

j 

•+■ 

/ 

/ 


.* 

I 

•+ 

/ 

/ 

'+ 

! 

•+ 

/ 

/ 


RESERVED 


BIT MAP - memory-resident TASKS 



+- 


-+ 

•-+ 




>34 

1 

PFZMRP 

I 

! 

BIT MAP 

- MEMORY-RESIDENT 

procedures 


+-■ 


-+ 

--4- 





/ 


/ 

/ 





/ 


/ 

/ 





+- 



--4- 




>54 

f 

+- 

PFZTSK 

j 

-+ 

1 

--+ 

BIT MAP 

- ALL TASKS 



/ 


/ 

/ 





/ 


/ 

/ 





+- 


-+ 





>74 

I 

PFZPRC 

i 

1 

BIT MAP 

- ALL PROCEDURES 



+- 


-+ 

--+ 





/ 


/ 

/ 





/ 


/ 

/ 





+- 


-+ 

--4- 




>94 

I 

PFZNRT 

1 

j 

BIT MAP 

- nonreplicatable 

TASKS 


+- 


-4- 

- — 4- 





/ 


/ 

/ 





/ 


/ 

/ 





+ “*■ 


- + 

“ — + 




>B4 

j 

+- 

PFZOVL 

1 

- + 

! 

--+ 

BIT MAP 

- ALL OVERLAYS 



/ 


/ 

/ 





/ 


/ 

/ 





+- 


- + 

— 4- 




>D4 

I 

PFZMNT 

! PFZTO 

1 

MAXIMUM 

NUMBER OF TASKS 



+- 


-+ 

-— 4" 

FIRST 

TASK DIRECTORY ENTRY OFFSET 

>D6 

I 

PFZTR 

1 

FIRST TASK DIRECTORY ENTRY 

REC # 


+- 


-+ 
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>D8 ! PFZMNP ! PFZPO ! MAXIMUM NUMBER OF PROCEDURES 


+ + + first proc directory entry offset 

>DA ! PFZPR ! FIRST PROC DIRECTORY ENTRY REC // 

+ + + 

>DC ! PFZMNO ! PFZOO ! MAXIMUM NUMBER OF OVERLAYS 

+ + + FIRST OVLY DIRECTORY ENTRY OFFSET 

>DE ! PFZOR ! FIRST OVLY DIRECTORY ENTRY REC # 

+ + + 

>E0 ! PFZMNH ! MAXIMUM NUMBER OF HOLES 

+ + + 

>E2 ! PFZHO ! FIRST AVAILABLE SPACE LIST OFFSET 

+ + r + 

>E4 ! PFZHR ! FIRST AVAILABLE SPACE LIST REC //t 

+ + + 

EQUATES ; 

LABEL EQUATE TO VALUE DESCRIPTION 


PFZSIZ $ >E6 SIZE OF INFORMATION SECTION OF REC 


Structure Pictures 
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4ei(*-k4fk-k-ifk4ck4fk'k4c‘k4(ickifk-k-kic‘k'k-k4ckitic'k-k -k ic kkkkkkkifkkifkifkk-ickicick-kkk’kk 
* * 

* QUEUE HEADER (QHR) 09/06/79 * 

* * 

* LOCATION: SYSTEM ROOT, JCA * 

•kkkkifkk'kifkifkk-kkkifffkk'kkifkkkififkkkkkkkkkkkkk'kkick-kk-kieickkkk'kk'kk-kk 

* QUEUE HEADERS FOR SYSTEM QUEUE SERVERS THAT RUN IN THE 

* SYSTEM JOB ARE BUILT DURING SYSTEM GENERATION IN THE 

* SYSTEM ROOT, QUEUE HEADERS FOR SYSTEM QUEUE SERVERS 

* THAT RUN IN A USER'S JOB ARE BUILD IN THE JCA WHEN THE 

* JOB IS CREATED. EACH QUEUE HEADER FOLLOWS THE QHR FORM. 


* + 


>00 

f 

QHRNEW 

f 

— 4- 

ADDRESS OF NEWEST 

ENTRY 

>02 

! 

QHROLD 

1 

! 

ADDRESS OF OLDEST 

ENTRY 

>04 

1 

QHRCNT ! 

J 

! QHRTID 

1 

— 

NUMBER OF ENTRIES 

C'T?'DT7T7'n fTAOV Tr\ 

ON 

QUEUE 

>06 

f 

QHRTSB 

! 

O iJ JA. V Xli XL/ 

TSB ADDRESS OF SERVER 

TASK 

>08 

“r“ 

I 

QHRJSB 

j 

JSB ADDRESS OF SERVER 

TASK 

>0A 

“r" 

! 

+- 

QHRLUN ! 

— H 

! FILLOO 

T 

1 

— + 

PROGRAM FILE LUNO 
RESERVED 

FOR 

SERVER 


EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


QHRSIZ $ >0C 
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* 

* QUEUED IP 

* 

•k 

k*********** 

* THE QIR I 

* CANNOT BE 


kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

k 

C REQUEST (QIR) 8/15/81 * 

k 

LOCATION: SYSTEM AREA * 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

S PUT ON THE IPC TASK QUEUE WHEN AN IPC REQUEST 
PROCESSED IN FAST TRANSFER IPC. 

** BEGINNING PACKED RECORD QIR 


* + k 

>00 I QIRQIR ! 

>02 ! QIRJSB ! 

>04 ! QIRCCB I 

+ + + 

>06 SIZE ** E 


POINTER TO NEXT QIR 

JSB ADDRESS OF OWNER 

(0 IF GLOBAL CHANNEL) 
ADDRESS OF CCB TO BE PROCESSED 

OF PACKED RECORD 


\ 


Structure Pictures 
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*it*ikiticfcki(i('k:ki::k4ticik*icicicifie4e-kit*4fkie'kie’k'k'kic-k-kicic'k^icic-k-k-kici(ickickifkici(icic'ic 
* * 

* REQUEST DESCRIPTION BLOCK (RDB) 05/21/79 * 

* ' * 

* LOCATION: RPSDAT AND SOME SVC PROCESSORS * 

■kic-kic'k-k-ickifk-k-kitifk-kidfkitifk’kieicifk-k-k-k-k-kiticic'kit^ic-k'kicic-k-k-k-k’kieicicii-k^iticifk^it 

* THE RDB FOR A GIVEN SVC SPECIFIES HOW TO BUFFER THE USER'S 

* REQUEST FOR PROCESSING BY THE SVC PROCESSOR, THE RDB IS 

* LOCATED IN THE MODULE RPSDAT BUILT DURING SYSTEM GENERATION 

* IF THE SVC IS AN OPTIONAL SVC OR IF THE SVC IS PROCESSED BY 

* A QUEUE SERVER TASK. OTHERWISE, THE RDB IS LOCATED IN 

* THE FIRST PROCESSOR MODULE FOR THE SVC PROCESSOR. AN RDB 

* EXISTS FOR A GIVEN SVC ONLY IF THE CALL BLOCK MUST BE 

* BUFFERED INTO A PORTION OF MEMORY FOR THE DURATION OF THE 

* PROCESSING. 



*_ 

+ 


>00 

j 

RDBFLG 

f 


+- 


-+ 

>02 

I 

RDBSRV 

j 


+- 

4- 

-+ 

>04 

i 

RDBRIB 

1 


+- 


— + 

>06 

1 

RDBMAX 

j 


+- 

— + 

— + 

>08 

1 

RDBBAS ! RDBACC 

1 


+- 

+ 

— + 

>0A 

1 

FILLOl 

j 


+- 

+ 

— + 

>0C 

j 

RDBEXP ! RDBLEN 

f 


+- 

+ 

— + 

>0E 

I 

RDBCOF ! RDBBOF 

f 


+- 

+ 

-+ 


DESCRIPTION FLAGS 

ADDRESS OF PROCESSOR ENTRY OR 

QUEUE HDR ADDRES S ( RDFQIJ=0 ) OR 
ADDRESS OF RETURN INFORMATION BLOCK 

MAXIMUM BUFFER LENGTH (BYTES) 

BASIC REQUEST BLOCK LENGTH (BYTES) 
ACCOUNTING WEIGHTING FACTOR 
RESERVED FOR FUTURE USE 

EXPANSION FLAGS 

EXPANSION LENGTH TO BUFFER 
OFFSET IN CALL BLOCK 

OFFSET IN BRB (0=CONTINUE FROM LAST 


FLAGS FOR FIELD: RDBFLG #00 


RDFEXT = (X ) 

RDFRST = ( .X ) 

RDFRPT = ( . ) 

RDFQOP = ( . . .X ) 

RDFSOD = ( . . . . X ) 

RDFDSJ = ( X ) 

RDFREV = ( X ) 

RDFINT = ( X ) 

* 

RDFQIJ = ( X ) 

= ( XXXXXXX) 


DESCRIPTION FLAGS 

EXTENSIONS TO THE RDB(1=YES) 
REQUIRES SYSTEM TASK (1=YES) 
REQUIRES SOFT. PRIVILEGED TASK 
QUEUE SERVER(O) OR PROCESSOR 
STATIC(O) OR DYNAMIC BUFFER 
DYNAMIC BUFFER - STA(O) OR JCA 
REVISING A BUFFER (1=YES) 
CAN(l) OR CANNOT(O) BE 
AN INITIATED EVENT 
QUEUE HDR IN STA(O) OR JCA 
RESERVED 


FLAGS FOR FIELD: RDBEXP #0C - EXPANSION FLAGS 
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RDFTYP = (X ) 

* 

* 

* 

* 

* 


RDFJCA = ( .X ) 

RDFMOR = ( . .X ) 

■k 

RDFJAV = ( . . .X ) 

= (....XXXX ) 

EQUATES : 

LABEL EQUATE TO VALUE 


RDBSIZ $ >10 


- TYPE OF CALL BLOCK OFFSET PTR 
0=START OF DATA WITH RDBLEN 

BYTES TO BUFFER 
l=POINTER TO EXPANSION 
BLOCK WITH OWN LENGTH 
BYTE AND DATA BUFFER 

- 1=BUFFER THIS IN JCA BY ITSELF 

- MORE EXPANSION BLOCKS (1=YES) 
(AFTER THIS ONE) 

- 1=WERE ABLE TO GET JCA SPACE 

- RESERVED 


DESCRIPTION 


Structure Pictures 
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kk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 
k k 

* RETURN INFORMATION BLOCK (RIB) 02/08/79 * 

* * 

* LOCATION: RPSDAT AND SVC PROCESSORS * 

k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k 

* THE RIB FOR A GIVEN SVC TELLS HOW MUCH AND WHERE TO 

* RETURN INFORMATION FROM A BUFFERED CALL BLOCK THAT WAS 

* USED BY THE SVC PROCESSOR. THE RIB IS IN THE MODULE 

* RPSDAT BUILT DURING SYSTEM GENERATION IF THE SVC IS AN 

* OPTIONAL SVC OR IS ONE PROCESSED BY A QUEUE SERVER TASK. 

* OTHERWISE THE RIB IS IN ONE OF THE SVC PROCESSOR MODULES. 

* THE RIB FOR A PARTICULAR SVC IS ACTUALLY SPECIFIED AS ONE 

* FIELD FOR RIBPRO, THEN ANY NUMBER OF PAIRS OF VALUES FOR 

* OFFSET AND LENGTH, THEN A WORD OF ZERO TO TERMINATE THE RIB. 


k — * 

>00 ! RIBPRO ! 

>02 ! RIBOFF ! RIBLEN ! 

EQUATES: 

LABEL EQUATE TO VALUE 


RIBSIZ $ >04 


POSTPROCESSOR (IF SPECIAL ONE) 

CALL BLOCK OFFSET 

LENGTH TO UNBUFFER (BYTES) 

DESCRIPTION 
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icifkifk-kieic^ieisii’kici:it*icitieikicie‘ifk-k’k * * * * 4fkic4cici(itici(*'ifk:kicitic:k'kieic4ck4eii-kiiit^ic:k’k'k 

* RECORD LOCK TABLE (RLT) 05/09/79 * 

* * 

* LOCATION: SYSTEM TABLE AREA OR USER JCA * 

* (WHEREVER FCB IS LOCATED) * 

******************************************** * * ****** * * ********* 


* FOR A FILE WHICH HAS LOCKED RECORDS, EACH LOCKED RECORD IS 

* REPRESENTED BY A RLT CHAINED TO THE FILE CONTROL BLOCK OF 

* THAT FILE. 


* -I * 


>00 

! 

RLTRLT 

! 

>02 

I 

RLTLDT 

! 

>04 

f 

RLTTSB 

1 

>06 

1 

RLTJSB 

! 

>08 

T — 

f 

RLTBN 

4 . 

I 


>0A I ! 

+ + + 


>0C I RLTOFF ! 


+ 



EQUATES : 

LABEL 

EQUATE TO 

VALUE 

RLTSIZ 

$ 

>0 


NEXT TABLE ENTRY ADDRESS 
LOCKING LDT ADDRESS 
LOCKING TSB ADDRESS 
OWNER JSB ADDRESS 
LOCKED BLOCK NUMBER 

LOCKED OFFSET 

DESCRIPTION 


Structure Pictures 
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ROB 


* * 

* RESOURCE OWNERSHIP BLOCK (ROB) 08/29/83 * 

* * 

* LOCATION: JCA * 

■kie4cikit4fkic‘kie-kic4e-kick-k-ki(ifk-ki:it4fkieie-k4c-k^ic-k4cic'kicic-k4fk'k‘kicicitickic'ieicic'it'k4c4cicifk 

* AN ROB IS BUILT FOR AN I/O RESOURCE WHEN AN ATTACH RESOURCE 

* OPERATION IS PERFORMED. THE ROB IS LINKED INTO THE ROB 

* LIST ANCHORED IN THE JCA'. 


— — — — — — — — — — — — — <-o4r 


>00 

f 

ROBROB 

! 

NEXT ROB 

ADDRESS 


+- 


— + 



>02 

I 

ROBACT ! ROBATN 

1 

ATTACHED 

COUNT 


+- 


— + 

ATTACH 

NUMBER 

>04 

1 

ROBFMT 

1 




+- 


-+ 



>06 

I 

ROBFCB 

f 




+- 


-+ 




EQUATES : 



LABEL 

EQUATE TO 

VALUE DESCRIPTION 

ROBSIZ 

$ 

>08 
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* * 

* RESOURCE PRIVILEGE BLOCK (RPB) 08/30/83 * 

* * 

* LOCATION: SYSTEM AREA OR JCA * 

************************************************************ 

* AN RPB IS BUILT FOR AN I/O RESOURCE WHEN A LUNO IS ASSIGNED. 

* IT IS ATTACHED TO THE APPROPRIATE RESOURCE STRUCTURE: CCB, 

* FCB, OR PDT. 


* H * 


>00 

! 

RPBRPB 

! 

link to next RPB 

>02 

! 

RPBFLG ! RPBCFI 

I 

FLAG BYTE 

CURRENT FILE INDEX (CONCAT. 
LDT ADDRESS 

>04 

"T “ 

RPBLDT 

f 

>06 

T* 

f 

RPBJSB 

I 

JSB ADDRESS 

>08 

T — 

i 

RPBLRN 

j 

LOGICAL RECORD NUMBER 

>0A 

T“* 

1 


I 


>0C 

"T — 

! 

RPBBN 

■•“r 

1 

BLOCK NUMBER 

>0E 

! 


! 


>10 

T** 

1 

RPBOCB 

1 

OFFSET IN CURRENT BLOCK 


+ + + 



FLAGS FOR 

FIELD: RPBFLG 

#02 

- FLAG BYTE 




RPFATT = 

(X 

...) - 

1 = 

ATTACHED 




RPFOPN = 

( .X 

...) - 

1 = 

LUNO OPEN 




RPFFBS = 

(..X 

...) - 

1 = 

FORWARD OR 

BACK 

SPACE 


= 

( . . .XXX 

...) - 

RESERVED 




RPFACU = 

( XX 

...) - 

ACCESS PRIVILEGES IN 

USE 

* 




00 

= EXCLUSIVE 

WRITE 


* 




01 

= EXCLUSIVE 

ALL 


* 




10 

= SHARED 



* 




11 

= READ ONLY 




EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


RPBACM >0300 
RPBMSZ $ 
RPBSIZ $ 


>300 ACCESS PRIVILEGES BIT MASK 

>08 MINIMUM SIZE 

>12 RPB SIZE 


Structure Pictures 


FILES ) 
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^4c^4cis4fitici(iffckit4ticiticititifkici<it4fk‘kifkieicifkieicie4citifk'k-kieic4c'k4t4tic-kick'ki(ifkiei(4t4( 
* * 

* RESERVE SEGMENT TABLE (RST) 09/21/81 * 

* * 

* LOCATION: JCA * 

************************************************************ 

* THE RST DESCRIBES ALL OF THE SEGMENTS THAT A JOB HAS 

* RESERVED WITH A RESERVE SEGMENT SVC CALL. 

* EACH ENTRY IS: 

* SEGMENT SSB ADDRESS 

* SEGMENT SMT ADDRESS 


MAX 

>00 ! RSTRST ! 

+ + + 

>02 ! RSTSID ! 

+ + + 

/ / / 

/ / / 

— — — — — — — — — H — — — — — — — — 

>22 ! FILLOO ! RSTALC ! 


NUMBER OF ENTRIES IN RST 
LINK TO NEXT RST 

ID'S OF RESERVED SEGMENTS (MAX 8) 
(ZERO IF ENTRY NOT IN USE) 


RESERVED FOR FUTURE USE 

NUMBER OF ALLOCATED ENTRIES (MAX 


8 ) 


EQUATES: 


LABEL EQUATE TO VALUE 


DESCRIPTION 


RSTCNT 8 
RSTSIZ $ 


>08 MAX NUMBER OF ENTRIES IN RST 
>24 
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* 

* SECONDARY ALLOCATION TABLE (SAT) 01/25/77 

* 

* LOCATION:JCA OR SYSTEM AREA, WITH FCB 

•kicicifkic'kie'k’kifkicii^icifklc-kifkifkifk'k-kie'kicieicicic'kic-kicic'k'k'kiclfk'kifkifkieifkifk-kic 


** 

* 

* 

* 

* 


* THE SAT SHOWS THE NUMBER AND LOCATION OF SECONDARY FILE 

* ALLOCATIONS. 


>00 

>02 

>04 




COUNT OF SAT ENTRIES 

* - 


* 


! 

SATASZ 

! 

ALLOCATION SIZE 

+- 


— — — — + 


1 

SATADU 

! 

ALLOCATION START 

+- 

+ 

+ 


1 

FILLOO ! 

1 

REMAINDER OF BLOCK 

+- 


+ 


/ 

/ 

/ 


/ 

/ 

/ 


+- 


h 



EQUATES ; 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 

SATNSA 

16 

>10 

COUNT OF SAT ENTRIES 

SATSIZ 

$ 

>40 



Structure Pictures 
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SCO 


***************************************************** 

* 

* TRACK 0, SECTOR 0 (SCO) 09/ 

* 

* LOCATION: TRACK 0, SECTOR 0 OF EACH 

***************************************************** 


******* 

* 

09/83 * 
* 

DISK * 
******* 


>00 

*- 

i 

SCOVNM ! 

-* 

1 


/ 

/ 

/ 

/ 

/ 

/ 

— 4. 

>08 

f 

SCOTNA 

I 

>0A 

! 

SCOSBM ! SC0T,BM 

I 

>0C 

“T — 

1 

SCORL 

f 

— 4- 

>0E 

“T — 

! 

SCOSLT 

f 

..4. 

>10 

I 

FILLOO ! 

j 

-4- 

>12 

*r — 

! 


1 

w4- 

>14 

"T* 

! 


f 

-4- 

>16 

“T — 

1 

SCONBA 

f 

«.4. 

>18 

I 

SCOSLE 

1 

— 4- 

>1A 

“r" 

I 

SCOSLL 

t 

— 4- 

>1C 

f 

FILLOl ! 

f 

— 4- 


'r— 

/ 

/ 

/ 

/ 

/ 

/ 

^4. 

>24 

•r— 

1 

SCOLTl 

j 

- 

>26 

“T — 

! 

FILL02 ! 

I 


•1““ 

/ 

/ 

/ 

/ 

/ 

/ 

—4- 

>2E 

"T — 

I 

SCOPIl ! 

J 

-4- 


/ 

/ 

/ 

/ 

/ 

/ 

— 4- 

>36 

“T"" 

? 

SC0PI2 ! 

1 


VOLUME NAME 

TOTAL SCO ADU ON DISK 

STARTING SECTOR OF BIT MAPS 
TOTAL SCO BIT MAPS 
TRACK 0 RECORD LENGTH 

SYSTEM LOADER TRACK ADDRESS 

* * RESERVED * * 

TOTAL SCO BAD ADU ON DISK 
SYSTEM LOADER ENTRY POINT 
SYSTEM LOADER LENGTH 

* * RESERVED * * 

SYSTEM LOADER TRACK (COPY 2) 

* * RESERVED * * 

PRIMARY SYSTEM FILE NAME 

SECONDARY SYSTEM FILE NAME 
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+ “* 
/ 

/ 


-+ 

/ 

/ 

/ 

/ 

>3E 

“T*"* 

f 

SCOPIF 

1 

>40 

f 

SCOVDA 

I 

>42 

! 

SCOVPL 

1 

>44 

"T — 

! 

SCOSPA 

J. 

1 

>46 

T"' 

1 

SCODCD 

1 

f 

>48 

! 


j 

O. «... 

j 

>4A 

“T*"' 

! 

SCOPFl 

1 

! 


"1" — 

/ 

/ 


/ 

/ 

-1_ 

/ 

/ 

>52 

"T — 

t 

SC0PF2 

I 

-4- 

! 


T — ' 

/ 

/ 


/ 

/ 

/ 

/ 

Mi «i4. 

>5A 

I 

SCOPFF 

J. 

I 

>5C 

T"* 

! 

SCOOFl 

f 

f 


"r“ 

/ 

/ 


/ 

/ 

-L 

/ 

/ 

>64 

! 

SCOOF2 

1 

j 


/ 

/ 


/ 

/ 

-1- 

/ 

/ 

>6C 

j 

SCOOFF 

1 

>6E 

“r“" 

I 

SCOILl 

t 

-l_ 

1 


T — 

/ 

/ 


/ 

/ 

/ 

/ 

>76 

•r~ 

j 

SC0IL2 

I 

J. 

! 


T — 

/ 

/ 


/ 

/ 

-L 

/ 

/ 

>7E 

i 

SCOILF 

-J_ 

I 

>80 

•T"* 

I 

SCODIN 

f 

I 


SYSTEM SELECTOR 

VOLUME DIRECTORY ADU SCO 

VCATALOG PHYSICAL RECORD LENGTH 

SECTORS/ADU 

DISK CREATION DATE 

PRIMARY PROGRAM FILE 

SECONDARY PROGRAM FILE 

PROGRAM FILE SWITCH 
PRIMARY OVERLAY FILE 

SECONDARY OVERLAY FILE 

OVERLAY FILE SWITCH 
PRIMARY INTERMEDIATE LOADER 

SECONDARY INTERMEDIATE LOADER 

INTERMEDIATE LOADER FLAG 
DIAGNOSTIC FILE NAME 


Structure Pictures 
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SCO 


+ + + 

/ / / 

/ / / 

+ + + 


>88 

! 

SCODIF 

t 

>8A 

"T*" 

1 

SCODRS 

j 

>8C 

! 

SCOBAL 

! 

>8E 

I 

SCOSPR 

1 

>90 

j 

SCOWFl ! 

! 


/ 

/ 

/ 

/ 

/ 

/ 

>98 

i 

SC0WF2 ! 

! 


/ 

/ 

/ 

/ 

/ 

/ 

>A0 

f 

SCOWFF 

! 

>A2 

I 

SCOVIF 

j 

>A4 

! 

SCOSTA 

1 

>A6 

j 

SCODCT 

! 

>A8 

! 

+- 

SCOFSF 

I 


EQUATES : 

LABEL EQUATE TO VALUE 


SCOSIZ $ >AA 


DIAGNOSTIC FLAG 
DBUILD DETERMINES DEFAULT PRS 
STARTING SECTOR OF BAD ADU LIST 
TRACK 0 SECTORS PER RECORD 
WCS PRIMARY microcode FILE 

WCS SECONDARY MICROCODE FILE 

WCS FLAG SWITCH 

TRACK 1 SELECT FLAG 

STATE OF DISK 

1 - NOT ANALYZED 
DISK CREATION TIME 

* * RESERVED * * 

DESCRIPTION 
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********************************************************** 

* 

* STAGE DESCRIPTOR BLOCK (SDB) 07/16/81 

* 

* LOCATION: A NAME DEFINITION SEGMENT 
********************************************************** 


** 

* 

* 

* 

* 

** 


*...-......4.-. ....* 


>00 

! 

SDBSDB 

! 


+- 


-+ 

— + 

>02 

1 

+- 

SDBCID 

! SDBSNO 

-+ 

I 

-+ 

>04 

I 

SDBTCT 

! SDBRES 

I 


+- 



-+ 

>06 

! 

SDBPAR 

f 


+- 


-+ 

-+ 

>08 

1 

SDBDEL 

1 


+- 



-+ 


FIXED LINK 

CREATOR TASK ID 
STAGE NUMBER 
TASK COUNT 
RESERVED 

POINTER TO PARENT SDB 
DESCENDANT ERROR LIST ANCHOR 


Structure Pictures 


22-152 


2270512-9701 



DNOS System Design Document 


SGB 


icit’k'k-kitifk-kicifkit'kifkifkieifkifffkifkidcic-k’kitiiiticickic'k^^eitititifkiciticicicic-kieicic-kiticic 
* * 

* SEGMENT GROUP BLOCK (SGB) 04/09/81 * 

* * 

* LOCATION: SEGMENT MANAGER TABLE AREA * 

-k-k'kic-k’k-k-k-k-kic-k'k'kickitifkicic-k-k'kicieititieic-kiciticicic’kitikifkieieicifkic-kititicicleicicidtiticit 


THE 

SGB 

IS AN ANCHOR FOR 

SSBS OF SEGMENTS WHICH FORM A 

LOGICAL 

SET, IT IS USED 

TO 

ACCESS SSBS FOR SEGMENT 

MANAGER 

CALLS MADE BY LUNO . 





* 

+ 





>00 

1 

SGBSGB 

I 

POINTER TO NEXT 

SGB 

IN TABLE 


+ 

+ 

•— + 




>02 

j 

SGBOMT 

! 

SMT SSB POINTER 

FOR 

OVERFLOW 


*h— — “ 

+ 

--+ 




>04 

1 

SGBOGB 

! 

SGB SSB POINTER 

FOR 

OVERFLOW 


+ 


•-+ 




>06 

1 

SGBSSB 

! 

SSB LIST HEADER 




+ 


■— + 




>08 

f 

SGBFLG 

j 

FLAGS 




+ 


■— + 




>0A 

1 

SGBFMT 

1 

FDP FOR THE SEGMENT 

GROUP 


+ 


--+ 




>0C 

1 

SGBFCB 

1 





+ 


•-+ 





FLAGS FOR FIELD: SGBFLG #08 - FLAGS 


SGFPFL = (X ) 

SGFDFL = ( .X ) 

SGFMBS = (..X ) 


SGFRES = ( . . .XXXXXXXXXXXXX) 
EQUATES : 


LABEL 

EQUATE TO 

VALUE 

SGBOSB 

SGBOMT 

>02 

SGBOLK 

SGBOGB 

>04 

SGBSIZ 

$ 

>0E 


PROGRAM FILE SEGMENT GROUP 
DATA FILE SEGMENT GROUP 
MEMORY-BASED SEGMENT GROUP 
RESERVED 


DESCRIPTION 


2270512-9701 


22-153 


Structure Pictures 



SLB 


DNOS System Design Document 


* * 

* SYSTEM LOG BLOCK FORMATS (SLB) 02/08/82 * 

* * 

* LOCATION: SYSTEM AREA * 

**********************************:fc********:lf******ifc********* 

* THIS TEMPLATE INCLUDES FORMATS FOR SEVERAL TYPES OF SYSTEM 

* LOG MESSAGES. EACH FORMAT INCLUDES THE SAME QUEUE LINK 

* FIELD AND FLAGS FIELD, EACH ALSO HAS A 4 BYTE TYPE FIELD. 

* OTHER FIELDS ARE PARTICULAR TO A TYPE OF LOG BLOCK BEING 

* BUILT. 


COMMON PORTION FOR ALL TYPES 

* H * 


>00 

! 

SLBSLB 

j 

QUEUE LINK 


+— 



-+ 


>02 

1 

SLBFLG 

! SLBCNT 

1 

BLOCK TYPE 


+- 


-+ 

-+ 

COUNT OF LOST MESSAGES 

>04 

1 

SLBDAY 

! 

BINARY DAY 


+- 



— + 


>06 

1 

SLBHR 

1 

BINARY HOUR 


+- 


-+ 

— + 


>08 

f 

SLBMIN 

1 

BINARY MINUTES 


+- 


- + : 

-+ 


>0A 

! 

SLBTYP 

j 

1 

LOG BLOCK TYPE 


+— 


- + 

-+ 



/ 


/ 

/ 



/ 


/ 

/ 



+- 



-+ 






TYPE 

1 - DEVICE ERROR WITH IMAGE 


*- 


— + — — — — — — 



>12 

I 

SLBEC 

! SLBSTI 

1 

ERROR CODE 


+- 


H 

-+ 

STATION ID 

>14 

! 

SLBJOB 

j 

JOB ID 


+- 



-+ 


>16 

! 

SLBIID 

! SLBRID 

1 

TASK INSTALLED ID 




-+ 

— + 

TASK RUN ID 


>18 

*- 

! 

SLBLUN 

f 

. 1 . 

SLBRTY 

-* 

! 

•a-l. 

LUNO 

RETRY COUNT 

RETRY SUCCESS(0)/FAILURE( 1 ) 
IMAGE WORD COUNT 

>1A 

T — 

I 

+ - 

SLBRSF 

j 

-+- 

SLBACT 

! 

- + 


* 


* 


> 1C ! 

SLBAIM 

I 

AFTER IMAGE 

+ 

+ 

— + 


/ 

/ 

/ 


/ 

/ 

/ 
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SLB 



+— 


-+ 



>2C 

1 

SLBBIM 

! 

BEFORE IMAGE 



+-■ 

+ 

-+ 




/ 

/ 

/ 




/ 

/ 

/ 




+-■ 

+ 

-+ 






TYPE 

2 - DEVICE ERROR WITH CALL 

BLO( 







>1C 

! 

SLBIRB 

! 

SPACE FOR 12 BYTES OF CALL 

BLK 


+-■ 

+ 

—+ 




/ 

/ 

/ 




/ 

/ 

/ 




+- 

+ 

-+ 






TYPE 

3 - ABNORMAL TASK TERMINATION 



+ 

^k 



>18 

! 

SLBWP 

1 

WORKSPACE POINTER AT ERROR 



+-■ 


-+ 



>1A 

I 

SLBPC 

! 

PROGRAM COUNTER 



+-■ 


-+ 



>1C 

! 

SLB ST 

! 

STATUS AT ERROR 



+- 

+ 

-+ 






TYPE 

4 - STATISTICS FROM A DSR 



k- 


-* 



>12 

! 

SLBRDG 

1 

NUMBER OF GOOD READS 



+- 





>14 

! 

SLBWRG 

! 

NUMBER OF GOOD WRITES 



+“ 


“•+ 



>16 

1 

SLBOTG 

! 

NUMBER OF GOOD OTHER OPS 



+“ 

+ 

-+ 



>18 

! 

SLBRDB 

1 

NUMBER OF BAD READS 



+- 

+ 

-+ 



>1A 

I 

SLBWRB 

! 

NUMBER OF BAD WRITES 



+- 

+ 




>1C 

! 

SLBOTB 

! 

NUMBER OF BAD OTHER OPS 



+- 

+ 







TYPE 

: 5 - USER ISSUED SYSTEM LOG 

SVC 


*- 

+ 




>12 

i 

SLBLEN ! FILLOO 

f 

length of USER MESSAGE 



+- 


-+ 

RESERVED 


>14 

! 

SLBUMS 1 

! 

USER MESSAGE BEGINS HERE 



+- 

+ 

-+ 




/ 

/ 

/ 




/ 

/ 

/ 




+- 

+ 





>0112 ! I 

+ + 


+ 


■k 


TYPE 6 
* 


MEMORY CACHE ERRORS 



SLB 
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>12 ! SLBANK ! SLBPRA ! BANK (A OR B) 

+ + + ADDRESS PARITY IN BANK A (G/B) 

>14 ! SLBPRB ! SLBBA6 ! ADDRESS PARITY IN BANK B (G/B) 

+ + + BASE ADDRESS OF CONTROLLER 

>16 ! SLBME6 ! SLBEVN ! AMOUNT OF MEMORY 

+ + + ERROR ON EVEN WORD (Y/N) 

>18 ! SLBAD6 ! TPCS ADDRESS 

+ + + 

TYPE 7 - MEMORY PARITY ERRORS 

■k :Ar 

>12 ! SLBBIT ! SLBROW ! BIT IN ERROR 

+ + + ROW IN ERROR 

>14 ! SLBCOR ! SLBBA7 ! CORRECTABLE? (Y/N) 

+ + + BASE ADDRESS OF CONTROLLER 

>16 ! SLBME7 ! SLBCTY ! AMOUNT OF MEMORY 

+ + + CONTROLLER TYPE 

>18 ! SLBAD7 ! TPCS ADDRESS 

+ + + 


EQUATES : 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 

SLBVRl 

$ 

>12 


SLBVR2 

$ 

>18 


SLBVR3 

$ 

>1C 


SLBSZ 1 

$-SLBSLB 

>3C 

DEVICE MESSAGE SIZE 

SLBSZ2 

$-SLBSLB 

>28 


SLBSZ3 

$-SLBSLB 

>1E 


SLBSZ4 

$-SLBSLB 

>1E 


SLBMXL 

255 

>FF 

MAX USER LENGTH 

SLBSZ5 

$-SLBSLB 

>113 


SLBSZ6 

$-SLBSLB 

>1A 


SLBSZ7 

$-SLBSLB 

>1A 
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* * 

* SEMAPHORE LIST HEADER (SLH) 03/15/79 * 

* * 

* LOCATION: JCA * 

******************************** ***:*f************************ 


* THE SLH IS USED TO DESCRIBE SEMAPHORES USED IN JOBS. FOR 

* EACH SEMAPHORE IN USE, THERE IS A LIST HEADER SHOWING THE 

* NUMBER OF THE SEMAPHORE, ITS VALUE, AND THE ENTRIES WAITING 

* FOR SEMAPHORE ACTION. 


* 1 * 


>00 

j 

SLHSLH 

f 


+- 


-+ 

>02 

! 

SLHVAL 

SLHNUM 

1 


+- 

+ 

- + 

>04 

f 

SLHNEW 

1 


+- 


-+ 

>06 

i 

SLHOLD 

i 


+- 

+ 

-+ 

>08 

f 

SLHCNT 

SLHTID 

j 


+- 

+ 

— + 

>0A 

I 

SLHTSB 

} 


+- 


— + 


NEXT SEMAPHORE ENTRY 

semaphore value 

SEMAPHORE NUMBER 


ADDRESS 

OF 

NEWE 

ST 

ENTRY 

ADDRESS 

OF 

OLDE 

ST 

ENTRY 

NUMBER 

OF 

ENTRI 

ES 

ON QUEUE 

SERVER 

TASK 

ID 

(NOT USED) 


TSB ADDRESS OF SERVER TASK(NU) 


EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


SLHSIZ 


>0C 
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* * * it * * * * *************************************************** 

* SEGMENT MANAGEMENT REQUEST (SMR) 11/05/81 * 

* * 

* LOCATION: SYSTEM TABLE AREA * 

*********************************************************** 

* THE SMR IS A SEGMENT MANAGEMENT SVC BLOCK WITH SEVERAL 

* ADDITIONAL FIELDS DEFINED FOR USE BY SEGMENT MANAGER 

* DURING PROCESSING OF THE SVC. 



*- 


-* 


>00 

1 

SMRSVC 

SMRERR 

1 

SVC CODE 


+- 

+ 

-+ 

ERROR CODE 

>02 

f 

SMROP 

SMRLUN 

I 

SEGMENT MANAGER SUB-OPCODE 


+- 


-+ 

logical unit 

>04 

I 

+- 

SMRFLG 

+ 

! 

-+ 

FLAGS 

>06 

I 

+- 

SMRNSl 

I 

— + 

NEW SEGMENT ID WORD 1 

>08 

1 

+- 

SMRNS2 

1 

-+ 

NEW SEGMENT ID WORD 2 

>0A 

j 

+- 

SMROSG 

+ 

I 

— + 

OLD SEGMENT ID 

>0C 

I 

+- 

SMRADR 

+ 

I 

-+ 

SEGMENT ADDRESS 

>0E 

! 

+- 

SMRLEN 

1 

— + 

SEGMENT LENGTH 

>10 

j 

+- 

SMRATR 

+ 

I 

-+ 

SEGMENT ATTRIBUTE (AS IN SSB) 

>12 

f 

+- 

SMRFMT 

I 

— h 

FDP ADDRESS 

>14 

j 

+- 

SMRFCB 

I 

-+ 



FLAGS FOR FIELD: SMRFLG /|f04 - FLAGS 


SMFINS = (X ) 

SMFNMD = ( .X ) 

SMFREL = ( . .X ) 

SMFMBS = ( . . .X ) 

SMFPOS = ( . . . .X ) 

* 

* 

SMFTSK = ( X ) 

SMFVLD = ( X ) 

SMFSRE = ( X ) 

SMFSEU = ( X ) 

* 

* 

SMFSYS = ( X ) 

= ( XXXX..) 


- INSTALLED ID 

- NOT MODIFIED 

- RELEASABLE 

- MEMORY BASED 

- 0 IF POSITION NUMBER SPECIFIED 

FOR OLD SEGMENT. 1 IF RUNTIME 
ID SPECIFIED. 

- TASK SEGMENT 

- VERIFY PROG. FILE LOAD ADDR 

- SET/RESET FLAG ENABLE 

- SET/RESET FLAG 

1=>SET EXCLUSIVE USE 
0=>RESET EXCLUSIVE USE 

- SYSTEM TASK 

~ ***reserved*** 
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SMR 


SMFPSN 


( 


XX) 


- POSITION NUMBER(1,2 


EQUATES : 
LABEL 
SMRSIZ 


EQUATE TO 

$ 


VALUE DESCRIPTION 
>16 


, OR 3) 
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************************************************************ 
* * 

* SEGMENT MANAGER TABLE (SMT) 1/30/79 * 

* * 

* LOCATION; USER MEMORY * 

************************************************************ 

* THE SMT IS THE TEMPLATE FOR THE STATIC DEFINITIONS IN 

* THE SEGMENT MANAGER SPECIAL TABLE AREAS. 


STARTS AFTER MM OVERHEAD 
* 1 * 


>00 

1 

SMTSGB 

1 

SGB LIST 

HEADER 


+- 

+ 

+ 



>02 

j 

SMTRID 

1 

LAST RUN 

ID allocated 


+- 

+ 

+ 



>04 

I 

SMTMAP ! 

1 

ALLOCATED 

RUN ID BIT MAP 


+- 

+ 

+ 




/ 

/ 

/ 




/ 

/ 

/ 




+- 

+ 

+ 
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SOB 


■k-k-kit^-kic-k-kick'k'krkickititickifkickifk-k'k-k'k-kifkikicic-kitie-k'k-k'kic'kicit'k-k'k-k-kifkickickitit 
* * 

* SEGMENT OWNER BLOCK (SOB) 09/23/81 * 

* * 

* LOCATION: SMT * 

***********************************’************************* 

* THE SOB IS USED TO IDENTIFY THE TASK WHICH HAS EXCLUSIVE 

* USE OF A SEGMENT. IT IS LINKED TO THE SSB. 


* 

>00 ! 

SOBJSB 

* 

j 

JSB ADDRESS OF 

SSB 

OWNER 

>02 ! 

SOBTSB 

f 

TSB ADDRESS OF 

SSB 

OWNER 

M 






EQUATES : 

LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 



SOBSIZ 

$ 

>04 
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************************************************************ 
* * 

* SYSTEM OVERLAY LOAD TABLE (SOV) 09/09/83 * 

* * 

* LOCATION: SYSTEM ROOT * 

************************************************************ 

* THE SOV IS BUILT DURING SYSTEM GENERATION AS PART OF THE 

* MODULE SOVT, DEPENDING ON THE OPTIONS CHOSEN DURING THE 

* GENERATION. THE FORMAT OF EACH ENTRY IS SHOWN IN THE OVT. 

** BEGINNING PACKED RECORD SOV 


>00 

i 

FMORWT 

1 

FM 


H 

+ 



>02 

1 


1 



+ 

+ 

+ 


>04 

f 


j 



+ 

+ 

+ 


>06 

I 

FMOMSC 

1 

FM 


+ 

+ 

+ 


>08 

! 


1 



+ 

+ 

+ 


>0A 

1 


1 



+ 

+ 

+ 


>0C 

1 

FMOEXT 

i 

FM 


+ 


+ 


>0E 

1 


1 



+ — 

+ 

+ 


>10 

f 


? 



+ 


+ 


>12 

1 

FMOOPX 

1 

FM 


+ 


+ 



>14 
>16 
>18 
> lA 
>1C 
>1E 
>20 
>22 
>24 
>26 


KMOINS 


KMODLS 


KMOOPC 


FM REWRITE RECORD OVERLAY 


! 

■+ 

f 

•+ 

I 

•+ 

f 

■+ 

I 

•+ 

1 

■+ 

I 

■+ 

I 

■+ 

I 

■+ 

f 


FM WEOF, CLOSE/EOF, OPEN REWIND, UNLK 


FM EXTEND FILE ALLOCATION OVERLAY 


FM OPEN EXTEND OVERLAY 


KM INSERT PROCESSOR 


KM DELETE AND SET CURRENCY 


KM OPEN AND CLOSE PROCESSORS 
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SOV 


>28 

J 





>2A 

I 

KMOBDE 

1 

KM 

DELETE SUBROUTINES 

>2C 

i 


( 



>2E 

! 


j 



>30 

! 

KMOBTI 

j 

KM 

B-TREE SPLIT FOR KMBTI 

>32 

I 


1 



>34 

j 


f 



>36 

1 

KMORWS 

I 

KM 

REWRITE SUBROUTINES 

>38 

1 


I 



>3A 

! 


j 



>3C 

! 

DMALLC 

! 

DM 

ALLOCATION SCAN OVERLAY 

>3E 

1 


j 



>40 

i 


I 



>42 

1 

DMCHPM 

f 

DM 

CHANGE PARTIAL BIT MAPS 

>44 

! 


! 



>46 

f 


t 



>48 

J 

CFDFOV 

j 

lU 

CREATE/DELETE FILE OVERLAY 

>4A 

1 


f 



>4C 

J 


f 

JL. 



>4E 

! 

OTHOVl 

f 

lU 

OTHER FUNCTIONS OVERLAY 

>50 

1 


1 



>52 

! 


} 



>54 

1 

OTHOV2 

I 

lU 

RF, AA, DA, CIC, DIC OVERLAY 

>56 

f 


1 



>58 

I 





>5A 

J 

+ 

PMERRS 

J 

+ 

PM 

ERROR PROCESSING SUBROUTINES 
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>5C 

>5E 

>60 

>62 

>64 

>66 

>68 

>6A 

>6C 

>6E 

>70 

>72 


I 

+ 

f 

+ 

j 

+ 

i 

-f. 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

I 

+ 

t 

+ 

SIZE 


KMOPLR 

SECMGR 

KMORWT 


+ 

I 

+ 

! KM PARTIAL LOG ERROR RECOVERY 

— — — + 

I 

+ 

! 

! lU SECURITY MANAGER OVERLAY 

I 

I 

+ 

! KM REWRITE MAIN ROUTINE 

+ 

I 

+ 

I 

+ 

** END OF PACKED RECORD 
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* * 

* SEGMENT STATUS BLOCK (SSB) 09/09/83 * 

* * 

* LOCATION: ROOT AND SEGMENT MANAGER TABLE AREA * 

**************!fc***************!fc*!fc***:fc*************5fc********* 

* EACH SEGMENT WHICH IS IN MEMORY IS DESCRIBED BY AN SSB. 

* THE SSB INCLUDES CHARACTERISTICS OF THE SEGMENT, LOCATION, 

* AND USE INFORMATION. 

* 

* SPECIAL FIELD COMMENTS: 

* 

* SSBWCT - THIS FIELD IS USED TO KEEP TRACK OF THE AMOUNT 

* OF FREE AREA IN A SPECIAL TABLE AREA. APPLIES 

* 

* 




TO SSB'S 

FOR 

SMT' S 

AND FMT'S. 

SSBI 

Dl/2 

- THIS FIELD 

CONTAINS THE BLOCK NUMBER FOR A 



SEGMENT 

WHICH 

IS 

ASSOCIATED WITH A DATA FILE. 


^ 







>00 

j 

SSBSSB 



I 

SSB LINK 


+ 

-h 

— 

— 

- + 


>02 

f 

SSBIDl 



! 

SEGMENT INSTALLED ID FIRST WORD 


+ 

— — — + ' 

— 

— 

- + 


>04 

f 

SSBID2 



1 

SEGMENT installed ID SECOND WORD 


+ 

+ 

— 

— 

- + 


>06 

! 

SSBRID 



J 

SEGMENT RUN-TIME ID 


+ 

+ 

— 

— 

- + 


>08 

J 

SSBATR 



1 

SEGMENT ATTRIBUTES 


+ 

+ 

— 

— 

- + 


>0A 

j 

SSBRCT 



j 

SEGMENT RESERVE COUNT 


+ 

+ 

— 

— 

- + 


>0C 

1 

SSBUCT 



1 

SEGMENT USE COUNT 


+ 

+ 

— 

— 

— + 


>0E 

J 

SSBSGB 



1 

SEGMENT GROUP BLOCK POINTER 


+ 

+ 

— 

— 

- + 


>10 

I 

SSBADR 



J 

SEGMENT BEET ADDRESS (PTS TO OVB+1) 


+ 

+-- 

— 

— 

- + 


>12 

j 

SSBLEN 



j 

LENGTH OF SEGMENT (BYTES) 


+ 


— 

— 



>14 

f 

SSBREC 



! 

REC. # OF PF SEG. ON HOME FILE 


+ 


— 

— 

-+ 


>16 

1 

SSBLOD 



{ 

LOAD ADDRESS OF SEGMENT (FROM P.F.) 


+ 

+ — 

— 

— 

•-+ 


>18 

I 

SSBFLG 



I 

SEGMENT FLAGS 


+ — — — * 

-f-__ 

— 

— 



>1A 

! SSBOVL ! 

SSBPRI 

j 

LAST OVERLAY NUMBER LOADED IN SEG 


+ 

+ — 

— 

— 

-— + 

INSTALLED PRIORITY (TASKS ONLY) 

>1C 

J 

SSBSTE 



1 

POINTER TO SWAP TABLE ENTRY 


^ 

+ 

— 

— 
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>1E ! SSBSOB ! POINTER TO SEGMENT OWNER BLOCK 

^ 1 

>20 ! SSBPRC ! SSBPR2 ! THE ID'S OF PROCEDURES ASSOCIATED 

4- + + with the task (TASK SEC ONLY) 

>22 ! SSBNAM ! ! TASK NAME (TASK SEC ONLY) 

+ + + 

/ / / 

/ / / 

+ + + 

FLAGS FOR FIELD: SSBATR #08 - SEGMENT ATTRIBUTES 

SSFRED = (X ) - READABLE (NONTASK) 

SSFSYS = (.X ) “ SYSTEM (BOTH) 

SSFRES = ( . .X ) - MEMORY RESIDENT (BOTH) 

= ( . . .X ) - RESERVED 

SSFREP = (....X ) - REPLICATABLE (BOTH) 

SSFSHR = ( X ) - SHARE PROTECT (NONTASK) 

SSFPR2 = ( X ) “ PROC 2 ON SYS P.F.(TASK) 

= ( X ) - RESERVED 

SSFOVF = ( X ) - OVERFLOW (TASK) 

SSFWCS = ( X ) - WRITEABLE CONTROL STORE (BOTH) 

SSFEXC = ( X ) - EXECUTE PROTECT (BOTH) 

SSFWRT = ( X....) - WRITE PROTECT (NONTASK) 

SSFUPD = ( X. ..) - UPDATEABLE (BOTH) 

SSFREU = ( X..) - REUSEABLE (BOTH) 

SSFCPY = ( X.) - COPYABLE (BOTH) 

SSFSEC = ( X) - SECURITY BYPASS (TASK) 

FLAGS FOR FIELD: SSBFLG #18 - SEGMENT FLAGS 
SSFTSK = (X ) - TASK SEGMENT 

SSFEMP = (.X ) - EMPTY SEGMENT (DO NOT LOAD) 

SSFHOM = (..X ) - LOAD FROM HOME FILE 

SSFINI = (...X ) - INITIAL LOAD SEGMENT (SSB NOT 

* INITIALIZED) 

SSFNRP = (....X ) “ DO NOT REPLICATE SSB (SINCE A 

* GET MEMORY WAS DONE) 

SSFREL = ( X ) - RELEASABLE 

SSFMOD = ( X ) - MODIFIED 

SSFMEM = ( X ) “ IN MEMORY 

SSFLLM = ( X ) - LOGICALLY IN MEMORY 

EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 


SSBWCT SSBIDl >02 UNALLOCATED WORDS IN SPECIAL TABLE 

SSFPRI SSFRED >00 PRIVILEGED (TASK) 

SSFPRl SSFSHR >05 PROC 1 ON SYS P.F.(TASK) 
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>0B software privileged (TASK) 

>20 BASIC SSB SIZE 

>2A TASK segment SSB SIZE 


2270512—9701 22—167 Structure Pictures 


SSFSPR SSFWRT 
SSBSIZ $ 
SSBTSZ $ 
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************************************************************ 


* * 

* SYSTEM TABLE AREA OVERHEAD (STA) 01/20/79 * 

* * 

* LOCATION: START OF ALL TABLE AREAS * 

************************************************************ 

* THE STA DESCRIBES OVERHEAD INFORMATION AT THE START OF 

* EACH OF THE SYSTEM TABLE AREAS: THE FILE MANAGEMENT TABLE 

* AREA, THE BUFFER TABLE AREA, THE SEGMENT MANAGEMENT TABLE 

* AREAS, AND THE STANDARD SYSTEM TABLE AREA. 



* 

+ 

* 

>00 

f 

STAHED 

! 


+ 

+ 

+ 

>02 

1 

STALNK 

1 


+ 

+ 


>04 

j 

STARES 

1 


-1 


+ 

>06 

I 

STAEND 

I 


+ 

+ 

+ 

>08 

I 

STAUSE 

I 


+ 


+ 

>0A 

? 

STAHI 

I 


+ 

+ 

+ 

>0C 

j 

STAPTR 

I 


H 

+ 



FIRST ENTRY ON FREE MEMORY LST 

POINTER TO FREE MEMORY CHAIN 

RESERVED TABLE AREA BOUNDRY 

ENDING ADDRES OF TABLE AREA 

CURRENT TABLE USAGE 

HIGHEST MEMORY ALLOCATION 

POINTER TO TABLE OWNER(jSB IF 
JCA OR SSB IF SPECIAL TABLE) 


EQUATES : 


LABEL EQUATE TO VALUE 


DESCRIPTION 


STASIZ 


>0E 
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* * 

* SWAP TABLE ENTRY (STE) 11/05/81 * 

* * 

* LOCATION: SYSTEM JCA * 


* FOR EACH SEGMENT ON THE SWAP FILE, THERE EXISTS AN STE 

* IN MEMORY, LINKED IN FILE RECORD ORDER ON THE FILE. THE 

* ANCHOR OF STES IS ROLDIR IN PMDATA. 


* H * 


>00 

1 

STERDT 

1 

>02 

1 

STEPRC 

! 

>04 

1 

STERRL 

1 

>06 

j 

STELDT 

+ 

j 


LINK TO NEXT STE 
ROLL FILE PHYS. RECORD NUMBER 
NUMBER RECORDS IN ROLL FILE 
CONTENTS OF OVBPTR 


EQUATES : 
LABEL 
STESIZ 


EQUATE TO 


$ 


VALUE DESCRIPTION 


>08 


STE 
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************************************************************** 
* * 


* TIME DELAY LIST ENTRY 

* 


(TDL) 03/15/78 * 

* 


* LOCATION: SYSTEM TABLE AREA * 

************************************************************** 


* A TDL DESCRIBES AN ENTRY ON THE TIME DELAY LIST, 




>00 

I 

TDLSVC 

+ 

1 

>02 

1 

TDLTMl 

+ 

I 

>04 

f 

TDLTM2 

j 


OP CODE (200) 
REACTIVATION TIME (WD 1) 


EQUATES : 

LABEL EQUATE TO VALUE DESCRIPTION 

TDLVAL $ >02 TIME DELAY VALUE 

TDLSIZ $ >06 SIZE OF BLOCK 
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* * 

* TASK STATUS BLOCK (TSB) 04/04/83 * 

* * 

* LOCATION: JCA * 

****************************:*:******************************* 

* EACH TASK WHICH HAS BEEN BID IS REPRESENTED BY A TSB IN 

* ITS JOB'S JCA. THE TSB INCLUDES STATE INFORMATION, LINKS 

* TO VARIOUS QUEUES, CHARACTERISTICS OF THE TASK, LOCATION 

* INFORMATION, MAPPING INFORMATION, AND STATISTICS COUNTERS. 

* 

* DETAILS ABOUT PARTICULAR FIELDS: 

* TSBTSK - OFFSET INTO MAP FILE AND SSB ADDRESSES FOR THE 

* SEGMENT THAT IS THE TASK SEGMENT (0=FIRST SEGMENT, 

* 4=SECOND SEGMENT, 8=THIRD SEGMENT) 

* 


* TSBIOI - I/O BOUND INDICATOR, MODIFIED BY THE SCHEDULER 

* 

* TSBGEN - GENERATION NUMBER IS ONE GREATER THAN THAT OF THE 

* PARENT OF THIS TASK. IF THE PARENT TASK DIES, THE 

* GENERATION NUMBER OF THIS TASK IS REDUCED BY 1, 

* AS ARE THE GENERATION NUMBERS OF ANY DESCENDENTS 

* OF THIS TASK. THIS VALUE IS 0 FOR QUEUE SERVERS. 

* 

* TSBSBN - SMT AND SSB PAIR FOR THE NEW SEGMENT WHEN A CHANGE 

* TSBSTN SEGMENT OPERATION IS ISSUED. TSBPSN IS THE 

* TSPPSN POSITION OF THE SEGMENT (0,4, OR 8). THESE ARE 

* USED ONLY WHEN THE SSB FOR THE NEW SEGMENT MUST 

* BE INITIALIZED. 

■k 

* TSBLSE - LOAD SEGMENT ENTRIES INCLUDE THE JCA AND ANY OTHER 

* SEGMENTS THAT NEED TO BE LOADED IN MEMORY WHEN 

* THIS TASK EXECUTES, THOUGH THEY MAY NOT BE MAPPED 

* IN TO THE TASK. 

k 

* TSBOSE - OWNED SEGMENTS ARE TEMPORARILY SHARE-PROTECTED 

* 

** BEGINNING PACKED RECORD TSB 


k 


>00 

! 

TSBQL 


! 


+- 

+-- 


— + 

>02 

! 

TSBWP 


! 


+- 

+ — 


-+ 

>04 

1 

TSBPC 


! 


+- 




-+ 

>06 

j 

TSBST 


1 


+- 

+-- 


-+ 

>08 

j 

TSBPRI ! 

TSBSTA 

1 


+- 


— 

-+ 

>0A 

1 

TSBIPR ! 

TSBINP 

1 


QUEUEING LINK FOR DYNAMIC QUEUES 

ACTIVE WORKSPACE POINTER 

ACTIVE PROGRAM COUNTER 

ACTIVE STATUS 

TASK priority (RUN TIME) 

TASK STATE 

INITIAL TASK PRIORITY 
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>oc 

+- 

! 

TSBIID ! TSBRID 

-+ 

1 

INSTALLED TASK PRIORITY 
INSTALLED TASK IDENTIFIER 

>0E 

J 

TSBSTG ! TSBIEC 

1 

KUN ilMh lAoK. IDENiiFlEK 

TASK STAGE NUMBER 

>10 

1 

TSBFLl 

I 

liMiiiAiJCjU tVEMi GUUINi 

TASK FLAGS - SYSTEM FLAGS 

>12 

f 

TSBFL2 

1 

TASK FLAGS - CONTROL FLAGS 

>14 

1 

TSBJSB 

! 

JSB ADDRESS 

>16 

1 

TSBXOP 

— T 

I 

EFFECTIVE XOP ADDRESS 

>18 

I 

TSBTSK ! TSBIO 

j 

2 WORD OFFSET TO TASK (0,4,8) 

> lA 

I 

TSBIOI ! TSBPSN 

I 

GEWEKAL 1/0 OOUIMl 

I/O BOUND INDICATOR 

>1C 

! 

TSBCPT 

i 

rUbiilUIN Ur JNEW bbi5 

CPU EXECUTION TIME (TICKS) 

> IE 

1 


""T 

I 


>20 

“T" 

f 

TSBRPC 

"•“T 

f 

NUMBER SERVICE CALLS ISSUED 

>22 

"T — 

I 


— T 

I 


>24 

1 

TSBBYl 

1 

NUMBER I/O BYTES TRANSFERRED 

>26 

i 

TSBBY2 

“•T 

1 

I/O BYTES TRANSFERRED - WORD 2 

>28 

“T" 

I 

TSBSPN 

•“T 

I 

TICK COUNTER AT TIME SUSPENDED 

>2A 

f 

TSBTSB 

! 

^4. 

TSB FIXED LINK IN SET FOR JOB 

>2C 

"T*" 

t 

TSBSTI ! TSBGEN 

f 

STATION ID (FF=NO STATION) 

>2E 

"T" 

1 

TSBPMl 

*““r 

J 

Vj F IN KA i 1 U IN JNUMJJLK 

PARAMETER 1 

>30 

•T"* 

f 

TSBPM2 

“T 

j 

«»_4. 

parameter 2 

>32 

“r — 

I 

TSBINl 

f 

^4. 

COMPLETED EVENT FLAGS - WORD 1 

>34 

f 

TSBIN2 

f 

.4. 

completed event flags - WORD 1 

>36 

T" • 

j 

TSBLDT 

f 

LDT LIST HEADER POINTER 

>38 

“r“ 

I 

TSBEOR 

“ T 

1 

END OF REQUEST PROCESSING 

T TCT UTTAnirP 

>3A 

"T — 

f 

TSBEAP 

f 

Lloi nijADriK 

END ACTION PROGRAM COUNTER 

>3C 

”r — 

f 

TSBEAW 

J 

END ACTION WORKSPACE 

>3E 

T 

I 

+ - 

TSBDIA 

+ 

! 

-+ 

END ACTION STATUS INFORMATION 
(DIAGNOSTIC DATA ADDRESS) 
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>40 

1 

TSBSBN 

1 


+ 


-+ 

>42 

1 

TSBSTN 

f 


+ 


-+ 

>44 

1 

TSBSB 1 

t 


+ 


-+ 

>46 

1 

TSBSTl 

1 


+ 


-+ 

>48 

1 

TSBSB2 

1 


+ 


-+ 

>4A 

! 

TSBST2 

1 


+ 

+ 

-+ 

>4C 

! 

TSBSB3 

! 


■i 


-+ 

>4E 

i 

TSBST3 

f 


+ 


-+ 

>50 

1 

TSBMLl 

1 


+ 


-+ 

>52 

j 

TSBMBl 

1 


+ 


-+ 

>54 

f 

TSBML2 

j 


+ 

+ 

”+ 

>56 

1 

TSBMB2 

1 


+ 

+ 

-+ 

>58 

j 

TSBML3 

f 


+ 

+ 

-+ 

>5A 

! 

TSBMB3 



+————■ 

+ 


>5C 

j 

TSBBLN 

i 


+ 

+ 

-+ 

>5E 

! 

TSBTLM 

f 


+ 


-+ 

>60 

1 

TSBMXM 

I 


+ 


-+ 

>62 

f 

TSBLSE 

j 


+ 

+ 


>64 

j 

TSBOSE 

j 


+ 

+ 

-+ 

>66 

1 

TSBSRT 

1 


+ 


“+ 

>68 

1 


1 


+ 

+ 

-+ 

>6A 

f 

TSBFMT 

j 


+ 


-+ 

>6C 

! 

TSBFCB 

j 


+ 


-+ 


TSB 

ADDRESS OF NEW SSB 

SM TABLE SSB FOR NEW SEGMENT 

SSB ADDRESS FOR 1ST SEGMENT 

SM TABLE SSB FOR 1ST SEGMENT 

SSB ADDRESS FOR 2ND SEGMENT 

SM TABLE SSB FOR 2ND SEGMENT 

SSB ADDRESS FOR 3RD SEGMENT 

SM TABLE SSB FOR 3RD SEGMENT 

MAP LIMIT ONE REGISTER 

MAP BIAS ONE REGISTER 

MAP LIMIT TWO REGISTER 

MAP BIAS TWO REGISTER 

MAP LIMIT THREE REGISTER 

MAP BIAS THREE REGISTER 

LENGTH OF MAPPED SEGMENTS (BEETS) 

TOTAL ROLLABLE MEMORY (BEETS) 

MAX VALUE OF TSBTLM 
LOAD SEGMENT ENTRY LIST HEADER 
OWNED segment ENTRY LIST HEADER 
TICK COUNTER WHEN TASK STARTED 

THE FDP OF PROGRAM FILE FOR 
THE TASK SEGMENT 


>6E ! 

+ 

>70 SIZE 


TSBAIC ! TSBRES ! ABORTING I/O COUNT 
+ + RESERVED 


** END OF PACKED RECORD 


FLAGS FOR FIELD: TSBFLl 


/MO - TASK FLAGS - SYSTEM FLAGS 
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TSFSYS = (X ) 

TSFPRI = (.X ) 

TSFMEM = ( . . X ) 

TSFENA = ( . . .X ) 

TSFIOA = ( . . . . X ) 

TSFABT = ( X ) 

TSFSEC = ( X ) 

TSFQSR = ( X ) 

TSFACT = ( X ) 

TSFBID = ( X ) 

TSFSPR = ( X ) 

TSFTOA = ( X. . . . ) 

TSFIOE = ( X. . . ) 

* 


- SYSTEM TASK 

- PRIVILEGED TASK 

- CURRENT segment SET IN MEMORY 

- TAKE END ACTION ON ERROR 

- I/O HAS BEEN ABORTED FOR TASK 

- TASK BEING ABORTED 

- BYPASS SECURITY 

- QUEUE SERVER TASK 

- ACTIVATE TASK OUTSTANDING 

- INITIAL TASK BID 

- SOFTWARE PRIVILEGE 

- ABORT TIMEOUT FLAG 

- I/O EVENT PEND. UNBUFF 

RESERVED - BITS 13 - 15 


FLAGS FOR FIELD: TSBFL2 #1 

TSFCNT = (X ) 

TSFSSC = ( .X ) 

TSFSBK = ( . .X ) 

TSFHLT = ( . . . X ) 

TSFRST = ( . . . . X ) 

TSFRBD = ( X ) 

TSFXOP = ( X ) 

TSFCHO = ( X ) 

* 


2 - TASK FLAGS - CONTROL FLAGS 

- TASK BEING CONTROLLED 

- STOPPED BY SCHEDULER 

- STOPPED BY BREAKPOINT 

- TASK TO BE HALTED 

- RESTART PARENT ON TERM 

- RBID TASK 

- REISSUE XOP 

- JOB-LOCAL CHANNEL OWNER 

RESERVED - BITS 8 - 15 
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* * 

* USER DESCRIPTOR OVERFLOW RECORD (UDO) 11/24/82 * 

* ' * 

* LOCATION: S$CLF ON DISK * 


*********************************************************** 

* THE UDO IS USED ONLY IN THE CASE THAT A USER IS A MEMBER 

* OF MORE ACCESS GROUPS THAN WILL FIT IN HIS UDR. IT CONTAINS 

* ACCESS GROUP INFORMATION. IT IS A VARIANT OF THE CAPABILITIES 

* LIST FILE RECORD ( CLR) . FOR DETAILS SEE CLR. 
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* * 

* USER DESCRIPTOR RECORD (UDR) 11/24/82 * 

* * 

* LOCATION: DISK * 


*********ilc************************************************* 

* THE UDR DESCRIBES THE DISK STRUCTURES THAT REPRESENTS A 

* GIVEN USER OF THE SYSTEM. IT INCLUDES LOGON INFORMATION 

* AND SECURITY INFORMATION. IT IS A VARIANT OF THE CAPABILITIES 

* LIST FILE RECORD (CLR). FOR DETAILS SEE CLR. 
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* * 

* USER ID PARAMETER (UIP) 12/01/82 * 

* * 

* LOCATION: POINTED TO BY IRBPRM FIELD * 

* * 


* 

* THE USER ID PARAMETER IS CHECKED BY SECURITY 

* MANAGER AND WILL BE USED IN PLACE OF THE 

* ISSUER'S USER ID IF A VALID PASSCODE IS 

* SUPPLIED OR THE TASK HAS SECURITY BYPASS. 

* THIS PARM MAY BE SUPPLIED BY A USER, OR 

* MAY BE CREATED BY lOU TO PASS INFO ACROSS 

* THE NETWORK. 

* 


>00 

I 

UIPSLN 

! 

UIPLEN ! 

>02 

j 

UIPUID 

! 

! 


“T** 

/ 

/ 


/ 

/ 

JL 

/ 

/ 

>0A 

T — 

I 

+ - 

UIPPWD 

j 

-+- 

f 

+ 


/ / / 

/ / / 

+ + + 


SUBLIST NUMBER (>02) 

LENGTH OF PARM-2 IN BYTES (>10) 
USER ID 


PASSWORD 


EQUATES ; 

LABEL EQUATE TO VALUE DESCRIPTION 

UIPSIZ $ >12 TOTAL LENGTH OF UIP 
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************************************************************ 

* VALUE CONTINUATION BLOCK (VCB) 07/16/81 * 

* * 

* LOCATION: A NAME DEFINITION SEGMENT * 

************************************************************ 


>00 ! 

VCBVCB 

.....* 

1 

POINTER TO NEXT 

NCB 

+ 





EQUATES : 

LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


VCBSIZ 

$ 

>02 

LENGTH OF NCB 

OVERHEAD 


Structure Pictures 


22-178 


2270512-9701 



DNOS System Design Document 


VDB 


*********************************************************** 

* VALUE DEFINITION BLOCK (VDB) 07/21/81 

* 

* LOCATION: NAME DEFINITION SEGMENT 

*********************************************************** 


* _ — * 

>00 ! VDBVCB ! 

+ + + 

>02 ! VDBUSE ! ! 

+ + + 


EQUATES: 

LABEL EQUATE TO VALUE 


VDBSIZ $ >03 


NEXT NAME CONTINUATION BLOCK 
NUMBER OF USERS OF THIS VALUE 

DESCRIPTION 

SIZE OF THE VDB OVERHEAD 
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***************************************************************:*:* 


* * 

* VIRTUAL REQUEST BLOCK (VRB) 8/22/83 * 

* * 

* LOCATION: SYSTEM TABLE AREA AND JCA * 

* * 


***************** * * ********************************************** 

* DEFINITIONS OF FIELDS IN DSR CALL BLOCK (DATA BUFFER FOR I/O 

* SVC SUBOPCODE >17) FOR VIRTUAL TERMINAL DSR. 

* 

** BEGI'NNING packed record VRB 



* - 


.* 


>00 

1 

VRBOC ! VRBEC 

1 

VTDSR REQUEST CODE 


+- 

+ 

-+ 

VTDSR RETURN CODE 

>02 

f 

VRBVT 

1 

VIRTUAL TERMINAL NUMBER (HEX) 


+- 


-+ 


>04 

I 

VRBCHR ! VRBLC 

j 

BID CHAR 


+- 


-+ 

LUNO USE COUNT 

>06 

1 

VRBJOB 

j 

PDTJOB 


+- 


- + 


>08 

f 

VRBRDN 

i 

REMOTE DEVICE NAME 


+— 


"+ 



/ 

/ 

/ 



/ 

/ . 

/ 



+- 


-+ 

t 

>16 

! 

VRBJID 

I 

REAL TERM JOB I.D. 


+- 


-+ 


>18 

1 

VRBIPC 

i 

OWNER IPC NAME 


+- 


- + 



/ 

/ 

/ 



/ 

/ 

/ 



+ *- 


-+ 


>24 

SIZE ** 

END 

OF PACKED RECORD 
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XTK 




EXTENTION FOR A 
WITH A 


TERMINAL 

KEYBOARD 


(XTK) 


02/12/82 


LOCATION: SYSTEM AREA 

* THE XTK IS AN EXTENSION TO THE PDT USED TO DESCRIBE A 

* DEVICE WITH A KEYBOARD. IT IS USED AS A WORK AREA BY 

* THE DSR. 


>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 
. >10 
>12 


* H * 

! XTKXUF ! 

! XTKFLG ! XTKSCH ! 

-I _ — ^ 

! XTKCRD ! 

+ + + 

! XTK I CD ! 

~ ~ ~ 

! XTKSSC ! 

H — 

! XTKABT ! 

+ — — — — — — — — — — — — — h 

! XTKTMO ! 

! XTKPFR ! 

+ + + 

! EDTFLO ! 

+ + + 

! EDTFLl ! 


EXTENDED USER FLAGS FROM BRB 

XTK general flags 

SAVED CHAR FOR JISCII TERMINAL 
CARRIAGE RETURN DELAY COUNT 

INTER-CHARACTER DELAY COUNT 

SAVED STATUS OF CASSETTES 

CODE ADDRESS TO PERFORM ABORT 

TIME-OUT COUNT FOR HANG CONDITION 

POWER FAIL FLAG/BUFFER BIAS 

EXTENDED EDIT FLAGS - WORD 0 

EXTENDED EDIT FLAG - WORD 1 


FLAGS FOR FIELD: XTKFLG #02 - XTK GENERAL FLAGS 


KSFHNG = (X ) 

KSFTMS = ( ) 

KSFSCI = (..X ) 

KSFDCD = ) 

KSFSIO = ( . . . . X ) 

KSFDIF = ( X ) 


HANG UP CONDITION ON 745 
TIME-OUT SWITCH FOR 745 
SCI ACTIVE DURING HANG UP 
DATA CARRIER DROP DETECTED 
SHIFT IN/SHIFT OUT JISCII 
DIRECT CHAR INPUT REQUESTED 


FLAGS FOR FIELD: EDTFLO #10 - EXTENDED EDIT FLAGS - WORD 0 


= (X ) - PASS-THROUGH MODE 

= (.X ) - 940-IN PTM, TERMINATE READ ON ETX 

= (..X ) “ 940-IN PTM, TERMINATE READ ON ESC-) 

= (...X ) - USED, BUT NOT DOCUMENTED 

= (....X ) - 940-disable use OF BIT 0 FOR INTEN 
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/ 



= 



.) 

- 

940-ALL0W ESC & SOH IN WRITE ASCII B 


= 

(.. 


.) 

- 

940-IGNORE DISPLAY CHARACTERS, ETC. 


= 

(.. 


o 

- 

940-1=132 COL MODE; 0=80 COL MOD 

MDTCHK 

= 

(.. 


.) 

- 

POST DATA MODIFIED ON READ 

EXVAL 

= 

(.. 


.) 

- 

EXTENDED CHAR VALIDATION 

NULFLG 

= 

(.. 


.) 

- 

NULL CHARACTER SUPPRESSION 

CNBFLG 

= 

(.. 


.) 

- 

CONVERT NULL TO BLANK 


= 

(.. 


. ) 

- 

KANJI 


= 



- 

RESERVED 


FLAGS FOR 

FIELD: EDTFLl 

#1 

2 ■ 

- EXTENDED 

EDIT 

FLAG - WORD 1 


=s 

(X 

. . . . ) 

— 

TERMINATE 

READ 

ON 

ERASE FIELD 


= 

( .X 

. . . . ) 

- 

TERMINATE 

READ 

ON 

RIGHT FIELD 

LEFARO 

= 

(..X 

— ) 

- 

TERMINATE 

READ 

ON 

LEFT ARROW 


= 

(...X. 

• • • • ) 

- 

TERMINATE 

READ 

ON 

TAB 


= 

( X 

— ) 

- 

TERMINATE 

READ 

ON 

UP ARROW 


= 

( X 

— ) 

- 

terminate 

READ 

ON 

SKIP 


= 

( X 

— ) 

- 

TERMINATE 

READ 

ON 

HOME 


= 

( X 

— ) 

- 

TERMINATE 

READ 

ON 

RETURN 


= 

( X... 

• • • • ) 

- 

TERMINATE 

READ 

ON 

ERASE INPUT 


= 

( X.. 

— ) 

- 

TERMINATE 

READ 

ON 

BLANK GRAY 


= 

( X. 

— ) 

- 

TERMINATE 

READ 

ON 

DELETE CHAR 


= 

( X 

. • • • ) 

- 

TERMINATE 

READ 

ON 

INSERT CHAR 

RITARO 

= 

( 

X. . . ) 

- 

TERMINATE 

READ 

ON 

RIGHT ARROW 


= 

( 

.X. . ) 

- 

TERMINATE 

READ 

ON 

ENTER 


= 

( 

. . X. ) 

- 

TERMINATE 

READ 

ON 

LEFT FIELD 


= 

( 

. . .X) 

- 

TERMINATE 

READ 

ON 

DOWN ARROW 


EQUATES ; 


LABEL 

EQUATE TO 

VALUE 

DESCRIPTION 


XTKFIL 

XTKFLG 

>02 

FILL CHARACTER 


XTKEVT 

XTKFLG+1 

>03 

EVENT CHARACTER 


XTKPOS 

XTKCRD 

>04 

WITHIN FIELD CURSOR 

POSITION 

XTKDEF 

XTKICD 

>06 

START OF FIELD CURSOR 

POSITION 

XTKJIN 

XTKSSC 

>08 

Ascii/jiscii intensity 

MASK 

XTKSCl 

XTKABT 

>0A 

SCRATCH it 1 


XTKSC2 

XTKTMO 

>0C 

SCRATCH it 2 


XTKSIZ 

$ 

>14 



XTKBUF 

XTKSIZ 

>14 

CHARACTER BUFFER 
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Appendix A 

Keycap Cross-Reference 


Generic keycap names that apply to all terminals are used for keys on keyboards throughout this 
manual. This appendix contains specific keyboard information to help you identify individual keys 
on any supported terminal. For instance, every terminal has an Attention key, but not all Attention 
keys look alike or have the same position on the keyboard. You can use the terminal information in 
this appendix to find the Attention key on any terminal. 

The terminals supported are the 931 VDT, 911 VDT, 915 VDT, 940 EVT, the Business System 
terminal, and hard-copy terminals (including teleprinter devices). The 820 KSR has been used as a 
typical hard-copy terminal. The 915 VDT keyboard information is the same as that for the 911 VDT 
except where noted in the tables. 

Appendix A contains three tables and keyboard drawings of the supported terminals. 

Table A-1 lists the generic keycap names alphabetically and provides illustrations of the 
corresponding keycaps on each of the currently supported keyboards. When you need to press 
two keys to obtain a function, both keys are shown in the table. For example, on the 940 EVT the 
Attention key function is activated by pressing and holding down the Shift key while pressing the 
key labeled PREV FORM NEXT. Table A-1 shows the generic keycap name as Attention, and a 
corresponding illustration shows a key labeled SHIFT above a key named PREV FORM NEXT. 

Function keys, such as FI, F2, and so on, are considered to be already generic and do not need 
further definition. However, a function key becomes generic when it does not appear on a certain 
keyboard but has an alternate key sequence. For that reason, the function keys are included in the 
table. 

Multiple key sequences and simultaneous keystrokes can also be described in generic keycap 
names that are applicable to all terminals. For example, you use a multiple key sequence and 
simultaneous keystrokes with the log-on function. You log on by pressing the Attention key, then 
holding down the Shift key while you press the exclamation (!) key. The same information in a table 
appears as Attentionl(Shift)! . 

Table A-2 shows some frequently used multiple key sequences. 

Table A-3 lists the generic names for 911 keycap designations used In previous manuals. You can 
use this table to translate existing documentation into generic keycap documentation. 

Figures A-1 through A-5 show diagrams of the 911 VDT, 915 VDT, 940 EVT, 931 VDT, and Business 
System terminal, respectively. Figure A-6 shows a diagram of the 820 KSR. 
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Table A-1. Generic Keycap Names 



'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service 
Routine (DSR). Keys on otherTPD devices may be missing or have different functions. 

''On a 915 VDT the Command Key has the label F9 and the Attention Key has the label F10, 
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Table A*1 . Generic.Keycap Names (Continued) 



Notes: 


'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service 
Routine (DSR). Keys on other TPD devices may be missing or have different functions. 
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T able A-1 . Generic Keycap Names (Continued) 



'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service 
Routine (DSR). Keys on other TPD devices may be missing or have different functions. 
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T able A-1 . Generic Keycap Names (Continued) 


Generic Name 


911 

VDT 


940 

EVT 


931 

VDT 


Business 

System 

Terminai 


820' 

KSR 


F11 




Fn 






m 


B 



F12 




n 

.F12 f 




Jil 




— rsi 


F13 




SHIFT O 

yjj.l r-.i 









B 


jaBt 




j[J|| 


L 





3 


iia|^ 




F14 



SHIFT O 


■ 


r: 


Home 


1 




% 


HOME 

f 

I 








HOME 

i 






Initiaiize input 





O 




Notes: 

'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service 
Routine (DSR). Keys on other TPD devices may be missing or have dillereni lunctions. 
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Table A-1 . Generic Keycap Names (Continued) 


Business 

System 

Terminal 



Notes: 

'The 820 KSR terminal has been used as a typical hard copy terminal with the TPD Device Service 
Routine (DSR). Keys on other TPD devices may be missing or have different functions 
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Table A-1. Generic Keycap Names (Continued) 


Generic Name 


911 

VDT 


940 

EVT 


931 

VDT 


Business 

System 

Terminal 


820' 

KSR 


Previous Line 


it! 

( — i— A 


B| 





m 



U 


Print 




if 


1 

PRINTii 






Repeat 


jRepeAfj 


See 
Note 3 


See 
Note 3 


See 
Note 3 


Return 




Shift 


■■■ 



SHIFT O 






[ 1 



1 , 1 


Skip 




17 

I 

TAB 

SKIP 

1 




SKIP 



Uppercase 

Lock 






Notes; 

'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service 
Routine (DSR). Keys on other TPD devices may be missing or have different functions. 


^The keyboard is typamatic, and no repeat key is needed. 
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Table A-2. Frequently Used Key Sequences 


Function 

Key Sequence 

Log-on 

Attention/(Shift)! 

Hard-break 

Attention/(Control)x 

Hold 

Attention 

Resume 

Any key 


Table A-3. 

911 Keycap Name Equivalents 

911 Phrase 

Generic Name 

Blank gray 

Initialize Input 

Blank orange 

Attention 

Down arrow 

Next Line 

Escape 

Exit 

Left arrow 

Previous Character 

Right arrow 

Next Character 

Up arrow 

Previous Line 
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DATA ENTRY 
KEYS 


0 

01 


to 

<b 

o 


Figure A-2. 915 VDT Standard Keyboard Layout 
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STATUS 8K ON/OFF REV SMOOTH 
TABS TABS LINE BKGND SCROLL 


SCROLL BRIGHT DIM CHAR CLICK 


SPEC KEY MARGIN HERE 
CHAR CLICK BELL IS 


RESET CONRGURE 


MARGIN 

LEFT RIGHT RELEASE CLEAR 
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Figure A-3. 940 EVT Standard Keyboard Layout 
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Figure A-4. 931 VDT Standard Keyboard Layout 


Keycap Cross-Reference 











2270512-9701 





te 

M 



■ 

till 

(i 

■ 


■ 

N 

R i 

l\ 

R : 
N : 



IMl 





2284734 ( 13 / 14 ) 


Figure A-5. Business System Terminal Standard Keyboard Layout 


Keycap Cross-Reference 





2270512-9701 



2284734 C\A/%A) 


Figure A-6. 820 KSR Standard Keyboard Layout 




DNOS System Design Document 


ALPHABETICAL INDEX 


Int.roduc 1 1 on 


The following Index lists key words and concepts from the subject 
material of this manual together with the area(s) In the manual 
that supply coverage of the listed concept. The numbers along 
with the right side of the listing reference the following manual 
areas : 

* Sections — References to Sections of the manual appear 
as ’’Section x” with the symbol x reresentlng any 
numeric quantity. 

* Appendixes — References to Appendixes of the manual 

appear as ’’Appendix y” with the symbol y representing 
any capital letter. 

* Paragraphs -- References to paragraphs of the manual 

appear as a series of alphanumeric or numeric 

characters punctuated with decimal points. Only the 
first character of the string may be a letter; all 

subsequent characters are numbers. The first 

chartacter refers to the section or appendix of the 
manual In which the paragraph Is found. 

* Tables — References to tables In the manual are 

represented by the capital letter T followed 

Immediately by another alphanumeric character 

(representing the section or appendix of the manual 
containing the table). The second character Is 

followed by a dash (-) and a number; 

Tx-yy 

* Figures — References to figures In the manual are 

represented by the capital letter F followed 

Immediately by another alphanumeric character 

(representing the section or appendix of the manual 
containing the figure). The second character Is 

followed by a dash (-) and a number: 

Fx-yy 

Should you be unable to find the Item of Interest In the Index, 
review the Table of Contents, List of Tables and List of Figures 
for general categories of Information. 
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CUT ALONG LINE 


USER’S RESPONSE SHEET 



Manual Date: 15 November 1983 Date of This Letter: 

User’s Name: Telephone: 

Company: ^ Office/Department: — 

Street Address: 

City/State/Zip Code: 

Please list any discrepancy found in this manual by page, paragraph, figure, or table number in the 
following space. If there are any other suggestions that you wish to make, feel free to include 
them. Thank you. 

Location in Manual Comment/Suggestion 
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FOLD ON TWO LINES (LOCATED ON REVERSE SIDE), TAPE AND MAIL 
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